Hello,
I'm testing throughput and latency of the TCP messages of various sizes.
I'm not testing, nor playing with the ethernet packet sizes. Since the
same testing was also done against other OpenBSD box with xl(4) NIC and
which behaves as expected, just with the slight drop in throughput around
the size of MTU, I don't think that such testing is pointless. IMHO also
sk(4) NIC and OpenBSD on this machine should behave in the same way --
slight drop in throughput around MTU size. I really do not expect to see
those speed/latency differences when the size of TCP message is just
different of few bytes and where the unexpected speed of 1.1Mbps is
bordered by the speeds of ~30Mbps. When I see something like this I'm
tempted to consider that something is broken. I'm just asking what it is,
if the driver (since OpenBSD/TCP/IP stack proofs it's able to manage this
testing scenario) or the hardware itself.
Anyway, the main reason behind this is that I'm doing some testing of
MICO's performance/latency of various sizes of GIOP messages. MICO is
CORBA implementation in C++: http://www.mico.org and GIOP/IIOP is the
CORBA protocol which uses TCPIP as an underlying transport mechanism.
Since MICO does not do any GIOP/IIOP message fragmentation itself (into
smaller TCPIP messages), I'm quite sure its latency will be affected by
the latency of the underlying TCPIP. Hence I'm using netpipe benchmark.
It's also interesting to see that my GigE NIC might be a way slower than
my fast ethernet under some specific circumstances.
Thanks,
Karel
On Tue, 23 May 2006, Chris Cappuccio wrote:
Testing packet sizes beyond the MTU is pointless unless you use that in a
real-world scenario. You are testing a lot more than the ethernet chip and
driver, in any event.
What are you testing for? It's not very clear from your original message.
Karel Gardas [EMAIL PROTECTED] wrote:
Henning Brauer wrote:
* Karel Gardas <[EMAIL PROTECTED]> [2006-05-23 15:55]:
So again some jumping around 1400 bytes.
The final question is: is this jumping behaviour caused by buggy drivers
in both OpenBSD and Linux or is this some kind of hardware behaviour
which
software is not able to workaround?
it is not at 1400, it is somewhere between 1400 and 1500. Given that
the MTU on ethernet tends to be 1500, this is no surprise - 1500 minus
headers. Above that you need >1 packets.
Yes, this is expected, but have you seen the pictures? Why do I get those
numbers:
Mbps size
0.000453 26.381993 12528 1566 0.000001 0.000001 0.000071 0.000000 0.000000
0.001532 7.823133 12568 1571 0.000000 0.000006 0.000076 0.000000 0.000000
0.000450 26.741679 12608 1576 0.000002 0.000003 0.000072 0.000000 0.000000
0.001527 7.900714 12648 1581 0.000001 0.000002 0.000081 0.000000 0.000000
0.000450 26.898181 12688 1586 0.000008 0.000000 0.000089 0.000000 0.000000
0.001971 6.157954 12728 1591 0.000002 0.000000 0.000080 0.000000 0.000000
0.000450 27.029827 12768 1596 0.000007 0.000000 0.000084 0.000000 0.000000
0.000450 27.160984 12808 1601 0.000000 0.000000 0.000094 0.000000 0.000000
...
0.000453 30.092254 14288 1786 0.000036 0.000000 0.000041 0.000000 0.000000
0.001536 8.893703 14328 1791 0.000008 0.000005 0.000084 0.000000 0.000000
0.004117 3.328115 14368 1796 0.000042 0.000000 0.000055 0.000000 0.000000
0.000455 30.203472 14408 1801 0.000235 0.000009 0.000102 0.000000 0.000000
0.012522 1.100382 14448 1806 0.000005 0.000003 0.000081 0.000000 0.000000
0.000453 30.507813 14488 1811 0.001304 0.000000 0.000029 0.000000 0.000000
0.005221 2.653563 14528 1816 0.000015 0.000001 0.000077 0.000000 0.000000
0.000456 30.487335 14568 1821 0.000256 0.000012 0.000095 0.000000 0.000000
0.001547 9.003794 14608 1826 0.000055 0.000004 0.000071 0.000000 0.000000
0.000456 30.650126 14648 1831 0.000123 0.000003 0.000087 0.000000 0.000000
0.010510 1.332744 14688 1836 0.000010 0.000001 0.000087 0.000000 0.000000
0.000459 30.587747 14728 1841 0.000575 0.000000 0.000121 0.000000 0.000000
I'm not against the fact that message of size 1806 bytes need to be
transfered in 2 ethernet packets, the problem is why I get 1.1Mbps
throughput with this size and get ~30Mbps with messages of 1801 and 1811
bytes? That's the reason why I'm asking if it is driver or hardware bug.
Note that numbers above are copied from the test where sk(4) was driven by
OpenBSD3.9-current.
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
--
There is no certainty, there is only opportunity
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
