Chat sends 100 bytes messages among the participants of the chat.
So that would explain the drop according to your observation.
We had similar experiences in with the scheduler. Sometimes we a
subsystem is speed up, you start hitting other bottlenecks, that were
previously not observed due to the dynamics of the benchmark.
Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability)
, OS-PIC (Chair)
(w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003
"David S. Miller" <davem@...>@lists.sourceforge.net on 05/31/2001
Sent by: lse-tech-admin@...
cc: lse-tech <lse-tech@...>
Subject: [Lse-tech] Re: Performance effects of zero-copy patch
Maneesh Soni writes:
> While measuring performance of read-copy mechanism and scalable FD
> patch in 2.4.4, I found that the chat benchmark's average throughput
> _less_ (~11%) then it used to be in 2.4.2. While narrowing down, the
> appears to be the zero-copy patch which was introduced in 2.4.4pre3
Does this chat room benchmark or the server it talks to do tiny
read/writes? If so, well the previous kernel preformed better moreso by
luck than anything else, and the performance is really limited by the
application in this case.
Also, does the benchmark or the server turn on the TCP_NODELAY socket
It might be interesting to see some network traces when this thing
runs to make sure we're not doing something truly stupid over the
I mean, a benchmark of a chat protocol is a complete oxymoron. Chat
room data patterns and TCP performance are at direct odds with each
David S. Miller
Lse-tech mailing list
Get latest updates about Open Source Projects, Conferences and News.