On Monday, December 17, 2007 Alexander Pevzner wrote:
> Serguei Osokine wrote:
>
>> As you can guess, there is no good reason why would the fake UDP
>> send take more time and effort than the real one - this probably
>> can be explained only by the bug in the IP stack. It is even quite
>
> First of all, loopback puts double load to your system - both
> transmit and receive paths are in use.
>
> Second, loopback in Windows is not a real interface. Its data
> flow is very different from a normal traffic. Normally, packets
> are transmitted via NDIS stack, but loopback is implemented purely
> in tcpip.sys.
>
> Third, I don't think that loopback path was ever optimized.
All true. Still, we are talking multiple orders of magnitude
performance difference here, not the double-load or anything even
remotely close to that. Despite all the factors that you're listing,
I'd still say that there's no good reason for the loopback to be
*that* slower than the real network interface. I would understand
half the performance. Maybe even a factor of ten difference. But
we're talking hundreds - you'd probably have trouble writing such
a slow code even if you'd wanted to.
At such a spectacular slowdown, it almost becomes a bug by
definition, regardless of whether there is a real bug there or
not. And I tend to think that there is a real bug, too - there
is this non-linear CPU load growth when the sending rate grows,
and this tends to be a bad sign; there is probably some multithread
synchronization behaviour there that is dramatically different from
what its designers intended it to be.
Best wishes -
S.Osokine.
17 Dec 2007.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alexander Pevzner
Sent: Monday, December 17, 2007 5:00 PM
To: [email protected]
Subject: Re: [p2p-hackers] MTU in the real world
Serguei Osokine wrote:
> As you can guess, there is no good reason why would the fake UDP
> send take more time and effort than the real one - this probably
> can be explained only by the bug in the IP stack. It is even quite
First of all, loopback puts double load to your system - both transmit
and receive paths are in use.
Second, loopback in Windows is not a real interface. Its data flow is
very different from a normal traffic. Normally, packets are transmitted
via NDIS stack, but loopback is implemented purely in tcpip.sys.
Third, I don't think that loopback path was ever optimized.
Though, once upon a time I've quickly benchmarked TCP (not UDP) via
loopback at both Windows and Linux. Windows was able to transmit ~80
megabytes per second. Linux - ~700 at the similar hardware. But this is
not a fair competition, because at Linux loopback traffic normally
bypasses TCP/IP stack (as a measure of optimization for XWindow system
running over loopback TCP).
I believe also that when you sendto() into the UDP socket in a blocking
mode, the sendto() call will block if output queue is full. By contrast,
linux will silently drop a packet at this case.
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
