Andy,
PPC->PPC is difficult because of limited (i.e. 2) prototype hardware platforms. PC->PC was interesting. Not even close (< 40mS to almost 2S). The sending PC had received a few TCP Window Size packets, while the PC->PPC connection had none. That leads me to believe (correct me if I'm wrong) that the receiving PPC is keeping up while the receiving PC couldn't, and had to reduce and re-expand the window. Would running lwIP on the PC be better or is the rest of the OS the problem? We have full control over the PC that is used with the PPC box. Thank you, Bill Auerbach _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 22, 2008 2:14 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] Which opt.h options effect TCP receive throughput? Bill, Now that you have a baseline, why not try sending PPC-->PPC and PC-->PC to get an idea of where any slowness might be? You might not even want to store the received data, just drop it on the floor. Andy "Bill Auerbach" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 01/22/2008 02:09 PM Please respond to Mailing list for lwIP users <[email protected]> To "'Mailing list for lwIP users'" <[email protected]> cc Subject [lwip-users] Which opt.h options effect TCP receive throughput? Hello, I'm still benchmarking lwIP TCP (PPC Power Arch) while receiving 2MB files to the PPC. I'm using raw api (call backs) and NO_SYS. 98% of the processor is processing lwIP timers and checking for Ethernet packets and the callbacks are doing the work. I have not moved to Jumbo (Huge) frames yet - I want to get standard packets as fast as possible. Interestingly, copying from the pbufs to contiguous memory is using about 10% of the bandwidth *including* using DMA to move the data (it was 40% with memcpy and 20% with an optimized memcpy). Right now I'm at 464MbS for a 2MB transfer. Finally the question of the subject line: Which lwIP options most effect receive throughput? Is it just these, which I've set as follows: #define TCP_WND (64*1024-1) #define TCP_MSS (8*1024) One thing I notice is there is an ACK sent for every 2 packets received. Does this sound right? (2874 received, 1437 sent). I tried a direct point to point link (PC to PPC box) with no change in the results. So the router is giving this burst everything - in fact I see no intervening packets in wireshark from the first to last TCP packet in my transfer (this surprised me actually). What is the theoretical limit with TCP? Is it the PC slowing things down, or am I simply close to "as good as it gets"? Thanks, Bill Auerbach _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
