User Tools

Site Tools


midd:traffic_scheduling:project_log

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
midd:traffic_scheduling:project_log [2009/04/12 17:19]
perryk
midd:traffic_scheduling:project_log [2009/04/13 21:40]
afbarnard added log entries for last week
Line 106: Line 106:
  
 AB - Got Mono up and running for C# development on Linux. Connected to Perry'​s databases. Traffic analysis is next. AB - Got Mono up and running for C# development on Linux. Connected to Perry'​s databases. Traffic analysis is next.
 +
 +
 +==== 04/06 ====
 +
 +AB, PK - Lunch meeting.
 +
 +AB - Filtered Perry'​s C# code to remove the "​unversionable"​ bits and committed it to our Subversion repository.
  
 ==== 04/08 ==== ==== 04/08 ====
  
 PK - researched and found a means of performing more high resolution timing in .net. PK - researched and found a means of performing more high resolution timing in .net.
 +
 +AB - Designed client analysis.
  
 ==== 04/09 ==== ==== 04/09 ====
Line 117: Line 126:
 ==== 04/10 ==== ==== 04/10 ====
  
-I was in the process of doing this (see above) when I could not reinstall the Spring ​drivers. Looking for a new set of drivers, I found a completely revamped set from Spring. Installing, and guess what - the NDIS adapter can not be directly seen by winpcap. Successfully sending and receiving via our software over the Sprint card to our server.+I was in the process of doing this (see above) when I could not reinstall the Sprint ​drivers. Looking for a new set of drivers, I found a completely revamped set from Sprint. Installing, and guess what - the NDIS adapter can not be directly seen by winpcap. Successfully sending and receiving via our software over the Sprint card to our server.
  
 ==== 04/12 ==== ==== 04/12 ====
  
-Learned some fascinating things about Windows networking. The metric you specify in the network settings doesn'​t do diddly. If you really want to change network metrics you have explicitly set metrics in the routing tables. I wrote a large TCP block sender plug-in. This caused a lot of opportunity to reassess the capture code. And, finally, caused a lot of pouring over wireshark captures comparing them to mine. This caused some learning about D-Link NIC options. Get this, in order to get fast performance with my NAS I enabled Jumbo packets (9KB). This is OK - as the NAS and my machine (and my switches) all understand Jumbo packets. The router doesn'​t so the negotiation between my machine and the router ​drops packet sizes back to normal for that path.. Turned out I had some other option on - Large Packet Offload. This is REALLY how large packets happen ​(32KB). But THIS OPTION doesn'​t get negotiated. So, when I blast something out to the Internet, I get huge numbers of retries because I'm sending ​32KB segments with the Don't Fragment flag set. So now I understand and can reconcile wireshark to my server and client logs. But I can't get optimum performance to my NAS and the Internet at the same time.  Spent 7 hours on this today.+Learned some fascinating things about Windows networking. The metric you specify in the network settings doesn'​t do diddly. If you really want to change network metrics you have explicitly set metrics in the routing tables. ​This is done by changing your default route for each adapter to the same thing with a new metric specified. THIS works. This was why my gigabit link would always take 2nd place to a 2 megabit link. The 2 megabit link showed up in the routine table with a metric of 80 while the gigabit link had a metric of 266! None of these numbers corresponded to the network metrics I specified in the adapter options. 
 + 
 +I wrote a large TCP block sender plug-in. This caused a lot of opportunity to reassess the capture code. And, finally, caused a lot of pouring over wireshark captures comparing them to mine. This caused some learning about D-Link NIC options. ​ 
 + 
 +I was seeing TCP packet with lengths near 64KB on the sending side (my machine) in the raw capture. This couldn'​t be says I. The receiving side (through the Internet) saw only normal Ethernet sized packets. There were a lot of lost segments and retires as the sender insisted it sent 64K and the receiver insisted it received only 1460 bytes. So pouring over wireshark I went. 
 + 
 +Get this, in order to get fast performance with my NAS I enabled Jumbo packets (9KB). This is OK - as the NAS and my machine (and my switches) all understand Jumbo packets. The router doesn'​t ​understand Jumbo packets ​so the negotiation between my machine and the router ​is SUPPOSED to drop packet sizes back to normal for that path. Turned out I had some other option on - Large Packet Offload. This is REALLY how large packets happen. But THIS OPTION doesn'​t get negotiated. So, when I blast something out to the router ​to the Internet, I get huge numbers of retries because I'm sending ​huge segments with the Don't Fragment flag set.  
 + 
 +So now I understand and can reconcile wireshark to my server and client logs. But I can't get optimum performance to my NAS AND the Internet at the same time.  Spent 7 hours on this all today.
  
 At this point I think the software is done to the point where meaningful capture is all there. Crud. I still have to send capture data from the server to the client when asked. I'll do this next. At this point I think the software is done to the point where meaningful capture is all there. Crud. I still have to send capture data from the server to the client when asked. I'll do this next.
 +
 +==== 04/12 ====
 +
 +Still coding. Added "​runid"​ to the UDP and both TCP plug-ins. The TCP case involved added a preamble (first bytes sent over the socket) so that both sides can have the same runid. I've had enough for today.
  
midd/traffic_scheduling/project_log.txt · Last modified: 2009/05/15 14:55 by afbarnard