HI , I am trying to do some performance measurements on lwip in Genode and RPI, I setup Genode on RPI and then run netperf_lwip from my client PC with Linux 12.04 as OS , Intel Core I7 I got
#netperf-2.6.0 -H 192.168.12.211 -P 1 -v 2 -t TCP_STREAM -c -C -- -m 1024 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.12.211 () port 0 AF_INET Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
131072 16384 1024 11.52 3.37 0.16 -1.00 30.938 -23.688
Alignment Offset Bytes Bytes Sends Bytes Recvs Local Remote Local Remote Xfered Per Per Send Recv Send Recv Send (avg) Recv (avg) 8 8 0 0 4978688 1024.00 4862 4534.32 1098
Maximum Segment Size (bytes) 1448
#netperf-2.6.0 -H 192.168.12.211 -P 1 -v 2 -t TCP_MAERTS -c -C -- -m 1024 MIGRATED TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.12.211 () port 0 AF_INET Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Recv Send Recv Send Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
131072 16384 1024 10.00 50.02 0.61 -1.00 8.007 -1.638
Alignment Offset Bytes Bytes Recvs Bytes Sends Local Remote Local Remote Xfered Per Per Recv Send Recv Send Recv (avg) Send (avg) 8 8 0 0 62524752 1449.82 43126 4096.00 15351
Maximum Segment Size (bytes) 1448
the Throughput values is looking strange!
when i run then netperf_lwip on genode based on linux platform i got totally different results
#netperf-2.6.0 -H 192.168.12.211 -P 1 -v 2 -t TCP_STREAM -c -C -- -m 1024 Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
131072 16384 1024 10.01 554.32 39.83 -1.00 47.089 -0.148
Alignment Offset Bytes Bytes Sends Bytes Recvs
Local Remote Local Remote Xfered Per Per
Send Recv Send Recv Send (avg) Recv (avg)
8 8 0 0 693644288 1024.00 677387 9572.39 72463
Maximum
Segment
Size (bytes)
1448
#netperf-2.6.0 -H 192.168.12.211 -P 1 -v 2 -t TCP_MAERTS -c -C -- -m 1024
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Recv Send Recv Send
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % U us/KB us/KB
131072 16384 1024 10.00 637.92 48.88 -1.00 50.219 -0.128
Alignment Offset Bytes Bytes Recvs Bytes Sends
Local Remote Local Remote Xfered Per Per
Recv Send Recv Send Recv (avg) Send (avg)
8 8 0 0 797411126 2621.83 304143 4096.00 194994
Maximum
Segment
Size (bytes)
1448
I would like to share this result and check if these value ok
best,
Hello,
your throughput value for TCP_MAERTS is in line with our nightly measurements but the value for TCP_STREAM seems to be far off. For reference, I have attached the output of the test run of last night, produced with the current staging branch.
Cheers Norman
Hi Norman, thank you for replaying.
actually i am using Genode with *rpi_usb branch *, is that give different results , in the other hand,I try to test from - LINUX 12.04 machine (core i7) - VM with OpenBSD 5.5 when i run the test from OpenBSD in the debug output of netperf in the Rpi I get meaasges like
[init] child "netserver_genode" request resources :ram_quota= XXXXX
and I get accepted value (in my point of view) for the throughput
while when I am running the test with the linux machine i dont even get these debug messages and i get the bad value for the throughput,
do you see any relation?
thank you in advance,
2014-11-03 10:50 GMT+01:00 Norman Feske <norman.feske@...1...>:
Hello,
your throughput value for TCP_MAERTS is in line with our nightly measurements but the value for TCP_STREAM seems to be far off. For reference, I have attached the output of the test run of last night, produced with the current staging branch.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Mohammad,
could you please switch to the current master branch? The "rpi_usb" branch is out of date. It was just a topic branch for the USB SOF optimzation, which ended up the master branch already.
I cannot explain your observation. To investigate, you may use wireshark to monitor the traffic in both cases (Linux vs. OpenBSD in the VM) and look for the TCP protocol parameters. Maybe Linux uses a very small TCP window in the bad case?
when i run the test from OpenBSD in the debug output of netperf in the Rpi I get meaasges like
[init] child "netserver_genode" request resources :ram_quota= XXXXX
We don't have these messages in our log but we use a different branch.
The messages should not interfere with the throughput. They just hint at a misconfiguration of the RAM quota assigned to the netserver_genode process. The process tries to allocate more memory than assigned. But since init has still slack memory available, it is handing out the needed memory on demand.
Cheers Norman
Hi Norman , I just moved this morning to the current master branch and i got the same bad result for the throughput (between 2 and 6 10^6 bits/sec)
I will try the wireshark to monitor the traffics and try to find the problem.
i will keep you updated.
best,
2014-11-04 11:58 GMT+01:00 Norman Feske <norman.feske@...1...>:
Hello Mohammad,
could you please switch to the current master branch? The "rpi_usb" branch is out of date. It was just a topic branch for the USB SOF optimzation, which ended up the master branch already.
I cannot explain your observation. To investigate, you may use wireshark to monitor the traffic in both cases (Linux vs. OpenBSD in the VM) and look for the TCP protocol parameters. Maybe Linux uses a very small TCP window in the bad case?
when i run the test from OpenBSD in the debug output of netperf in the Rpi I get meaasges like
[init] child "netserver_genode" request resources :ram_quota= XXXXX
We don't have these messages in our log but we use a different branch.
The messages should not interfere with the throughput. They just hint at a misconfiguration of the RAM quota assigned to the netserver_genode process. The process tries to allocate more memory than assigned. But since init has still slack memory available, it is handing out the needed memory on demand.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Norman, I used the WireShark to monitor the Traffic , when i measure the TCP_STREAM the tcp packet from the linux to rpi has small window size ( 229 ) while it is around (18000) from rpi to the Linux ,
is that the problem , should i try to change this value and what is the regulare value to use it ?
best ,
2014-11-04 3:57 GMT-08:00 Mohammad Hamad <mhh.it1986@...9...>:
Hi Norman , I just moved this morning to the current master branch and i got the same bad result for the throughput (between 2 and 6 10^6 bits/sec)
I will try the wireshark to monitor the traffics and try to find the problem.
i will keep you updated.
best,
2014-11-04 11:58 GMT+01:00 Norman Feske <norman.feske@...1...>:
Hello Mohammad,
could you please switch to the current master branch? The "rpi_usb" branch is out of date. It was just a topic branch for the USB SOF optimzation, which ended up the master branch already.
I cannot explain your observation. To investigate, you may use wireshark to monitor the traffic in both cases (Linux vs. OpenBSD in the VM) and look for the TCP protocol parameters. Maybe Linux uses a very small TCP window in the bad case?
when i run the test from OpenBSD in the debug output of netperf in the Rpi I get meaasges like
[init] child "netserver_genode" request resources :ram_quota= XXXXX
We don't have these messages in our log but we use a different branch.
The messages should not interfere with the throughput. They just hint at a misconfiguration of the RAM quota assigned to the netserver_genode process. The process tries to allocate more memory than assigned. But since init has still slack memory available, it is handing out the needed memory on demand.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Norman ,
I am still getting same small numbers for the throughput when testing the network performance for the Raspberry pi with the TCP_STREAM,
you mentioned that your test results are different ,
could you tell me please what you use in the client machine side,
by using TCP_MAERTS my results are almost same to yours,
best,
2014-11-06 13:45 GMT+01:00 Mohammad Hamad <mhh.it1986@...9...>:
Hi Norman, I used the WireShark to monitor the Traffic , when i measure the TCP_STREAM the tcp packet from the linux to rpi has small window size ( 229 ) while it is around (18000) from rpi to the Linux ,
is that the problem , should i try to change this value and what is the regulare value to use it ?
best ,
2014-11-04 3:57 GMT-08:00 Mohammad Hamad <mhh.it1986@...9...>:
Hi Norman ,
I just moved this morning to the current master branch and i got the same bad result for the throughput (between 2 and 6 10^6 bits/sec)
I will try the wireshark to monitor the traffics and try to find the problem.
i will keep you updated.
best,
2014-11-04 11:58 GMT+01:00 Norman Feske <norman.feske@...1...>:
Hello Mohammad,
could you please switch to the current master branch? The "rpi_usb" branch is out of date. It was just a topic branch for the USB SOF optimzation, which ended up the master branch already.
I cannot explain your observation. To investigate, you may use wireshark to monitor the traffic in both cases (Linux vs. OpenBSD in the VM) and look for the TCP protocol parameters. Maybe Linux uses a very small TCP window in the bad case?
when i run the test from OpenBSD in the debug output of netperf in
the
Rpi I get meaasges like
[init] child "netserver_genode" request resources :ram_quota= XXXXX
We don't have these messages in our log but we use a different branch.
The messages should not interfere with the throughput. They just hint at a misconfiguration of the RAM quota assigned to the netserver_genode process. The process tries to allocate more memory than assigned. But since init has still slack memory available, it is handing out the needed memory on demand.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Mohammad,
I am still getting same small numbers for the throughput when testing the network performance for the Raspberry pi with the TCP_STREAM,
the small TCP window size you observed seems to be the limiting factor. But I have no idea why the TCP connection throttles the window parameters in this way.
Have you tried any of the following experiments to encircle the problem?
* Different host machine * Different OS on your host machine. You mentioned that the problem does not occur when running OpenBSD in a VM on the host machine. How is the behavior when running OpenBSD natively on the host machine? * Different network equipment (network cables, switch) * Different Raspberry Pi * Different power supply for the Raspberry Pi * Performing the netperf test with Raspian
could you tell me please what you use in the client machine side,
We run our nightly tests on Ubuntu 12.04.4 LTS (GNU/Linux 3.2.0-67-generic x86_64).
Have you tried to follow (and possibly instrument) the lwIP code that is involved in the TCP parameter negotiation?
Cheers Norman
-
Mhamad Hmad -
Mohammad Hamad -
Norman Feske