Re: CAsyncSocket and performance issues

The Nagel Algorithm is one reason the OP can't depend on reading 8 bytes and getting all
the data. Other reasons include basic packetizing, network packet delays, flow control in
the lower-level TCP stack.

I had a 100-Base-T network (now I have 1G) but with that network and three machines
feeding data in to me, I saturated at 1300 packets/min, with an average packet size of 80.
I believe this was due to the fairly heavy-duty processing time each packet required, but
our benchmark was a customer required a minimum of 400/min, so we were within the required
performance with lots of headroom, so I never investigated beyond that.

The suggestion of updating the progress bar based on a timer is a good one, and you should
look into that as well, if it turns out the progress bar update is the performance
bottleneck.
joe

On Wed, 30 Mar 2005 21:46:45 -0700, Jerry Coffin <jcoffin@xxxxxxxxx> wrote:

>In article <1112239522.811192.171640@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
>danceswithbikers@xxxxxxxxxxx says...
>
>[ ... ]
>
>> Well, I thought about this, but from my perspective, it seemed as
>> though I was just adding another layer of bufferage that would only add
>> to the overhead. After all, ever call to Receive() draws on a buffer.
>> What good does it do to draw from one buffer and write to another? You
>> see what I'm saying? Are you quite sure that this principle is
>> irrelevant to tcp/ip subsystems?
>
>There's extra overhead in making extra copies. There's also, however,
>overhead when you make a call to Windows to read data. Copying more
>data at a time adds overhead in one place but reduces it in the
>other.
>
>The question is whether the reduction is greater than the increase or
>vice versa. My guess is that it'll reduce the overhead (a lot) in
>this case.
>
>> Similarly, even though out-going CChunks are usually only 15 bytes
>> or so long, I assumed that the CPU would be sending them out so fast,
>> that overtime, a large collection of them would form one large packet.
>> Perhaps I was wrong. Perhaps each successful, or partially successful,
>> write to a socket produces exactly one packet.
>
>This is what the Nagel algorithm does. It's also "smart" enough to be
>fairly smart about how long it waits accumulating data before it
>sends out a packet.
>
>Sending tiny amounts at a time still has overhead though, much like
>above: even though it's accumulating enough data to send out packets
>of reasonable size (saving overhead in what's transmitted over the
>wire) switches from user mode to kernel mode and back still have
>overhead in CPU usage, and it sounds like you're probably doing them
>pretty frequently.
>
>> I suppose that is something I could buffer. Rather than increasing
>> the progress bar every 20 bytes, I could accumulate an offset value and
>> update the bar every 15k or so.
>
>I wouldn't do either one. No matter what amount you pick, it's going
>to be ridiculous in some situation -- if you pick large enough chunks
>to make sense on 10 Gigabit Ethernet, it'll only update every few
>hours if somebody runs the program over a dial-up connection. If you
>go the other direction, and update often enough to make sense over a
>dial-up connection, it'll end up trying to update thousands of times
>per second over a fast network.
>
>Instead, I'd consider simply setting a timer for somewhere between
>100 and 1000 milliseconds, and update the progress control when it
>fires, regardless of how much data that happens to represent. This
>automatically updates the display at a reasonable rate regardless of
>connection speed. Exactly how fast you decide to update in that range
>is mostly a matter of taste -- 100 ms is really faster than most
>people can read the updates, so it gives an impression of things
>really "moving", even if they're not. Updating once a second gives a
>more "relaxed" feel to things, even though it reduces CPU usage, so
>the transfer itself might be moving a tiny bit faster.

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: CAsyncSocket and performance issues
    ... ever call to Receivedraws on a buffer. ... There's extra overhead in making extra copies. ... a large collection of them would form one large packet. ... hours if somebody runs the program over a dial-up connection. ...
    (microsoft.public.vc.mfc)
  • Re: bites, bytes, packets, TCP, and DSL speed
    ... there will be 18 bytes of overhead per frame (source and destination MAC ... of overhead (version, header length, type of service, packet length, ... assuming the network can carry full-size Ethernet frames end-to-end, ... Packets larger than your line's MTU size will be fragmented at the IP ...
    (comp.sys.mac.comm)
  • Re: sendfile(2) SF_NOPUSH flag proposal
    ... >>at the start of a transaction and turned off at the end of a transaction. ... it's unintentionally fragging up to one packet ... The overhead of toggling it would be costly. ... > change is cheap" to justify adding this feature. ...
    (freebsd-arch)
  • Re: FreeBSD handles leapsecond correctly
    ... :never ever passes a packet again until a down/up on the receiving interface. ... considering that we haven't removed the MP lock from the network ... The single biggest overhead we have right now is that we have not ...
    (freebsd-current)
  • Re: FreeBSD handles leapsecond correctly
    ... >:I've been testing network and routing performance over the past two weeks ... >:never ever passes a packet again until a down/up on the receiving interface. ... > between 3 uS and 1.2 uS per packet of overhead. ... > serialized down to effectively 1 cpu due to the MP lock. ...
    (freebsd-current)