Re: bizarre network timing problem

2007-11-06 Thread Rick Jones
Felix von Leitner wrote: Thus spake Rick Jones ([EMAIL PROTECTED]): Past performance is no guarantee of current correctness :) And over an Ethernet, there will be a very different set of both timings and TCP segment sizes compared to loopback. My guess is that you will find setting the lo m

Re: bizarre network timing problem

2007-11-02 Thread Felix von Leitner
Thus spake Rick Jones ([EMAIL PROTECTED]): > Past performance is no guarantee of current correctness :) And over an > Ethernet, there will be a very different set of both timings and TCP > segment sizes compared to loopback. > My guess is that you will find setting the lo mtu to 1500 a very >

Re: bizarre network timing problem

2007-11-02 Thread Rick Jones
Felix von Leitner wrote: Thus spake Rick Jones ([EMAIL PROTECTED]): Oh I'm pretty sure it's not my application, because my application performs well over ethernet, which is after all its purpose. Also I see the write, the TCP uncork, then a pause, and then the packet leaving. Well, a wise ol

Re: bizarre network timing problem

2007-11-02 Thread Felix von Leitner
Thus spake Rick Jones ([EMAIL PROTECTED]): > >Oh I'm pretty sure it's not my application, because my application performs > >well over ethernet, which is after all its purpose. Also I see the > >write, the TCP uncork, then a pause, and then the packet leaving. > Well, a wise old engineer tried to

Re: bizarre network timing problem

2007-11-02 Thread Rick Jones
Felix von Leitner wrote: Thus spake Rick Jones ([EMAIL PROTECTED]): How could I test this theory? Can you take another trace that isn't so "cooked?" One that just sticks with TCP-level and below stuff? Sorry for taking so long. Here is a tcpdump. The side on port 445 is the SMB server

Re: bizarre network timing problem

2007-11-02 Thread Felix von Leitner
Thus spake Rick Jones ([EMAIL PROTECTED]): > >How could I test this theory? > Can you take another trace that isn't so "cooked?" One that just sticks > with TCP-level and below stuff? Sorry for taking so long. Here is a tcpdump. The side on port 445 is the SMB server using TCP_CORK. 23:03:20.

Re: bizarre network timing problem

2007-10-18 Thread Rick Jones
Felix von Leitner wrote: the packet trace was a bit too cooked perhaps, but there were indications that at times the TCP window was going to zero - perhaps something with window updates or persist timers? Does TCP use different window sizes on loopback? Why is this not happening on ethernet?

Re: bizarre network timing problem

2007-10-18 Thread Felix von Leitner
> the packet trace was a bit too cooked perhaps, but there were indications > that at times the TCP window was going to zero - perhaps something with > window updates or persist timers? Does TCP use different window sizes on loopback? Why is this not happening on ethernet? How could I test thi

Re: bizarre network timing problem

2007-10-17 Thread Rick Jones
the packet trace was a bit too cooked perhaps, but there were indications that at times the TCP window was going to zero - perhaps something with window updates or persist timers? rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL P

Re: bizarre network timing problem

2007-10-17 Thread Felix von Leitner
Thus spake Chuck Ebbert ([EMAIL PROTECTED]): > > Any ideas what could cause this? > (cc: netdev) Maybe I should mention this, too: accept(5, {sa_family=AF_INET6, sin6_port=htons(59821), inet_pton(AF_INET6, ":::127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [18446744069414584348

Re: bizarre network timing problem

2007-10-17 Thread Chuck Ebbert
On 10/17/2007 04:51 PM, Felix von Leitner wrote: > I wrote a small read-only SMB server, and wanted to see how fast it was. > So I used smbget to download a moderately large file from it via localhost. > smbget only got ~70 KB/sec. > > This is what the view from strace -tt on the server is: > > 2