tuning for upstream speeds.

OK, situation is I would like to squeeze as much as I can out of
upstream connectyion.

Sync is fine at 448k, but actual throughput is down at 376k consistently.

Now I know there is always some overhead, but what is the best way to
minimise that..is there an optimal MTU size?

Currently its 1400.


Or anything else?

The Natural Philosopher wrote:
> OK, situation is I would like to squeeze as much as I can out of
> upstream connectyion.
>
> Sync is fine at 448k, but actual throughput is down at 376k consistently.
>
> Now I know there is always some overhead, but what is the best way to
> minimise that..is there an optimal MTU size?

Assuming you connect with pppoa + vcmux then 1478 should be optimal.

> Or anything else?

If your sender is Linux you could save 12 bytes/packet by turning off
tcp timestamps.

Andy Furniss wrote:
> The Natural Philosopher wrote:
>> OK, situation is I would like to squeeze as much as I can out of
>> upstream connectyion.
>>
>> Sync is fine at 448k, but actual throughput is down at 376k consistently.
>>
>> Now I know there is always some overhead, but what is the best way to
>> minimise that..is there an optimal MTU size?
>
> Assuming you connect with pppoa + vcmux then 1478 should be optimal.
>

Oddly enough, I cant seem to change it in te router. Stiuck at 1400
whatever I try and change it to.

>> Or anything else?
>
> If your sender is Linux you could save 12 bytes/packet by turning off
> tcp timestamps.
>

That's a neat idea

What's the command? Sender IS Linux..

On Thu, 04 Mar 2010 20:51:22 +0000, The Natural Philosopher wrote:

> Andy Furniss wrote:
>> The Natural Philosopher wrote:

>>> Sync is fine at 448k, but actual throughput is down at 376k
>>> consistently.
>>> Now I know there is always some overhead, but what is the best way to
>>> minimise that..is there an optimal MTU size?

This is ATM overheads we're looking at here. I doubt there's anything you
can do about it. Depending on line length you may get a lot more out of
ADSL2+, failing that, IPstream Max Premium is capped at 800k rather than
400k up.

>> If your sender is Linux you could save 12 bytes/packet by turning off
>> tcp timestamps.
>>
>>
> That's a neat idea
>
> What's the command? Sender IS Linux..

echo 0 > /proc/sys/net/ipv4/tcp_timestamps

--
<http://ale.cx/> (AIM:troffasky) ((E-Mail Removed))
21:08:31 up 17 days, 1:59, 4 users, load average: 0.00, 0.06, 0.24
DIMENSION-CONTROLLING FORT DOH HAS NOW BEEN DEMOLISHED,
AND TIME STARTED FLOWING REVERSELY

alexd wrote:
> On Thu, 04 Mar 2010 20:51:22 +0000, The Natural Philosopher wrote:
>
>> Andy Furniss wrote:
>>> The Natural Philosopher wrote:
>
>>>> Sync is fine at 448k, but actual throughput is down at 376k
>>>> consistently.
>>>> Now I know there is always some overhead, but what is the best way to
>>>> minimise that..is there an optimal MTU size?
>
> This is ATM overheads we're looking at here. I doubt there's anything you
> can do about it. Depending on line length you may get a lot more out of
> ADSL2+, failing that, IPstream Max Premium is capped at 800k rather than
> 400k up.
>

costs money. No adsl2 available :-(

>>> If your sender is Linux you could save 12 bytes/packet by turning off
>>> tcp timestamps.
>>>
>>>
>> That's a neat idea
>>
>> What's the command? Sender IS Linux..
>
> echo 0 > /proc/sys/net/ipv4/tcp_timestamps
>
376k -> 380K! oh well its something..

thanks!

Does that setting survive a reboot?

The Natural Philosopher wrote:

>> Assuming you connect with pppoa + vcmux then 1478 should be optimal.
>>
> Oddly enough, I cant seem to change it in te router. Stiuck at 1400
> whatever I try and change it to.

That's a shame. I prefer to leave mine at 1500 and set things up for
less elsewhere.

>> If your sender is Linux you could save 12 bytes/packet by turning off
>> tcp timestamps.
>
> That's a neat idea
>
> What's the command? Sender IS Linux..

echo 0 > /proc/sys/net/ipv4/tcp_timestamps

I do that in a boot script - but then I use a half finished LFS and
don't have sysctl, I guess you will, so that would be the way to make
it stick for you.

alexd wrote:

> This is ATM overheads we're looking at here.

ATM cell = 53 bytes so if you arrange for MTU to exactly fill the cells
you won't waste bandwidth sending an extra cell that's not all data.

I know the difference isn't that much and you loose some data vs fixed
overheads by reducing packet size, but 1478 still beats 1500 and both
beat 1400.

448kbit = 1056 cells/sec (and modems do round down to do their cell
level QOS) Assuming timestamps off for the following.

Fixed AAL5 overhead using pppoa/vcmux = 10, ATM payload = 48 bytes.
Fixed ip overhead = 20, tcp overhead = 20.
Rounding up to whole cells if required as AAL5 has to pad.

(1500 + 10)/48 = 32. (1056/32)*(1500-40)*8 = 385440 bits/sec payload

(1478 + 10)/48 = 31. (1056/31)*(1478-40)*8 = 391878

(1400 + 10)/48 = 30. (1056/30)*(1400-40)*8 = 382976

On Thu, 04 Mar 2010 22:15:29 +0000, Andy Furniss wrote:

> Fixed AAL5 overhead using pppoa/vcmux = 10,

Does PPP add overhead per-packet [or cell]? Or is it just at the
beginning/end of a session?

--
<http://ale.cx/> (AIM:troffasky) ((E-Mail Removed))
21:51:49 up 18 days, 2:43, 4 users, load average: 0.00, 0.02, 0.00
It is better to have been wasted and then sober
than to never have been wasted at all

alexd wrote:
> On Thu, 04 Mar 2010 22:15:29 +0000, Andy Furniss wrote:
>
>> Fixed AAL5 overhead using pppoa/vcmux = 10,
>
> Does PPP add overhead per-packet [or cell]? Or is it just at the
> beginning/end of a session?

According to RFC 2364 it's per packet, 2 bytes of the 10 are ppp
protocol ID. It actually says 8 or 16 bits, empirically it's 16.