Kenneth Culver wrote:
> > You should visit the FreeBSD -performance list archives for a
> > (fairly) recent discussion on network performance (I believe
> > between a couple of us, we were able to come up with tuning
> > parameters that improved someone's file transfer performance by
> > about a fa
> You should visit the FreeBSD -performance list archives for a
> (fairly) recent discussion on network performance (I believe
> between a couple of us, we were able to come up with tuning
> parameters that improved someone's file transfer performance by
> about a factor of 10 for some tests).
Rem
Kenneth Culver wrote:
> > Just as an experiment, try setting "net.inet.tcp.newreno" to 0 using
> > sysctl(8). It might help; it might not. Please let us know.
>
> It didn't help. I also tried setting several other sysctl OID's in
> net.inet.tcp, but nothing helped. I'm totally out of ideas for w
> This is the data transfer, so the d2c_* plots are the interesting ones
> (they graph the traffic from ftp2 to you). If you load up d2c_tput.xpl,
> you can see that your throughput averaged ~164K/s for almost the entire
> time. The red line is the short-term average, and you can see there
> were
In the last episode (Jul 09), Kenneth Culver said:
> > In the last episode (Jul 09), Kenneth Culver said:
> > > > look of any large values in the timestamps and see if there is
> > > > anything before that indicates a lost packet or a re-ordered one or
> > > > something (or a retransmitted ack)
> >
> In the last episode (Jul 09), Kenneth Culver said:
> > > look of any large values in the timestamps and see if there is
> > > anything before that indicates a lost packet or a re-ordered one or
> > > something (or a retransmitted ack)
> > >
> > > The key is to find the gap in the arriving packets
In the last episode (Jul 09), Kenneth Culver said:
> > look of any large values in the timestamps and see if there is
> > anything before that indicates a lost packet or a re-ordered one or
> > something (or a retransmitted ack)
> >
> > The key is to find the gap in the arriving packets and figure
> > > Can you do a
> > > 'netstat -s -p tcp >> tcpstats' before and after the transfer?
> > >
> > > This should tell us if there were retransmits etc. It could be a
> > > difference in minimum rtt values or a congestion issue that results in
> > > timeout for our stack but some other recovery mech
On Wed, 9 Jul 2003, Kenneth Culver wrote:
> > Can you do a
> > 'netstat -s -p tcp >> tcpstats' before and after the transfer?
> >
> > This should tell us if there were retransmits etc. It could be a
> > difference in minimum rtt values or a congestion issue that results in
> > timeout for our s
> > Transferring anything through the BSD NAT box shows the same performance
> > issues, as well as transferring directly from BSD to the DSL modem on both
> > of my BSD machines. Using windows or the mac directly connected to the DSL
> > modem shows the normal bandwidth capability. I know the hard
On Wed, 9 Jul 2003, Kenneth Culver wrote:
> > AH so it's direct DSL with either a fixed IP or DHCP or similar?
>
> Yep, basically I don't have a DSL modem, I have an Ethernet to ATM bridge
> (using AAL5 encapsulation I believe) running over the DSL. I have 2 fixed
> IP's, and in my normal configur
> AH so it's direct DSL with either a fixed IP or DHCP or similar?
Yep, basically I don't have a DSL modem, I have an Ethernet to ATM bridge
(using AAL5 encapsulation I believe) running over the DSL. I have 2 fixed
IP's, and in my normal configuration, my two BSD boxes are hooked up to a
switch th
On Wed, 9 Jul 2003, Kenneth Culver wrote:
> > I think he is timing transfers from a Mac THROUGH the BSD box..
> > If so then a change in throughput would be due to a change in ppp
> > behaviour..
>
> No, I hooked the mac straight to the DSL modem, and also did the same with
> the windows box.
>
> Just as an experiment, try setting "net.inet.tcp.newreno" to 0 using
> sysctl(8). It might help; it might not. Please let us know.
It didn't help. I also tried setting several other sysctl OID's in
net.inet.tcp, but nothing helped. I'm totally out of ideas for why this
could be happening. I me
> I think he is timing transfers from a Mac THROUGH the BSD box..
> If so then a change in throughput would be due to a change in ppp
> behaviour..
No, I hooked the mac straight to the DSL modem, and also did the same with
the windows box.
>
> It would be interesting to see if it changed with
> 1/
In article <[EMAIL PROTECTED]>,
Julian Elischer <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 9 Jul 2003, John Polstra wrote:
>
> > In article <[EMAIL PROTECTED]>,
> > Kenneth Culver <[EMAIL PROTECTED]> wrote:
> > > Recently, for some wierd reason, with FreeBSD-CURRENT my DSL
> > > downloads have
On Wed, 9 Jul 2003, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Kenneth Culver <[EMAIL PROTECTED]> wrote:
> > Recently, for some wierd reason, with FreeBSD-CURRENT my DSL
> > downloads have gotten about 10-15 KB/sec slower than they used to be.. I
> > used to get 160KB/sec downl
In article <[EMAIL PROTECTED]>,
Kenneth Culver <[EMAIL PROTECTED]> wrote:
> Recently, for some wierd reason, with FreeBSD-CURRENT my DSL
> downloads have gotten about 10-15 KB/sec slower than they used to be.. I
> used to get 160KB/sec downloads, and now can only manage about 145. I was
> wo
Hi,
Recently, for some wierd reason, with FreeBSD-CURRENT my DSL
downloads have gotten about 10-15 KB/sec slower than they used to be.. I
used to get 160KB/sec downloads, and now can only manage about 145. I was
wondering if there are any ideas what is causing this. I'm sure it's a
FreeBSD
19 matches
Mail list logo
