Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

I'm traffic shaping the traffic coming from the LAN into my Firebrick router as it is pushed out through IP packet traffic-shaper / rate limiter software components into the modems to head on upstream. The traffic shaping has a manually configured bit rate which defines the upstream max that each modem can handle going into the DSL line. See pic
    https://c2.staticflickr.com/2/1531/24681753249_76e4ba156d_h.jpg

This pic shows the throughput measured by a speed tester server. It's the upstream graph I'm interested in here. Notice the ripple, a kind of 'hunting'-type pattern shown as the upstream traffic never manages to settle down completely to a stable rate as seen in the other, downstream, throughput graph. This ripple is presumably due to TCP's natural operation anyway. Thoughts?

• Is this a (slightly) bad thing?
• Should I be aiming for proper stability / convergence as in the other graph?
• I'm presumably overdriving it? I've set the traffic shaper limit too high compared with the real capacity of the pipe. Is that correct?
• How do I try to strike a balance between overdriving, which presumably implies packet loss, and throughput? I presumably have to think about VoIP as I'm a VoIP user and need to worry a lot about packet loss under heavy load?
  

[burakkucat]

I see a similar effect when using the same throughput speed tester. Interestingly it is not so pronounced in this latest test, performed just a few minutes ago.

As I do nothing special -- with just the one circuit in ADSL2 mode -- and can see a comparable effect with what you have shown, I would be more inclined to categorise it as an artefact of the throughput speed tester.

[Weaver]

I'm thinking that the speed tester itself maybe incorporates its own kind of traffic shaping using timed UDP packets instead of using a TCP subsystem that can't be controlled and overridden so easily for the purposes of groping maximum traffic rates. Are you thinking likewise?

[Weaver]

Whatever it isn't suitable for checking out the healthy functioning of a typical TCP system on the upstream, when we don't even know we are using TCP! In that case, as you say, we're just seeing the timing pattern that is a product of the speedtester's upload test algorithm.

[Weaver]

I wonder what to make of the fact that we don't see the distinctive sawtooth pattern on the other, downstream, graph. Either it's different code in the servers, or the BRAS is overriding the timing in the downstream sequence and smoothing it all out. Is that possible?

[burakkucat]

I honestly do not know what to make of it. 

You could, of course, ask TBB's Saffy, as he is the author.

[d2d4j]

Hi

If it helps, a speedtest server in a datacentre is not limited other then the connected allocation speed (usually circa 1gb or 100mbps, burstable) and the only way to test this, is DC to DC, and even then, is hard to push to full speed if on 1gb or greater. Other test are needed which can push further on speeds but at cost to computer which is used to start the test, not the speedtest server.

Also, it goes out on port 80, which is TCP only, usually defined in firewalls/load balancers, multiplexers.

This then removes this side from your connection test, ie ISP as they will have their own balancing policies.

I believe this, as we are a test server for speedguide, but I have already stated this previously and we know our racks/setup as we only rent the racks, all other equipment is ours, and we can precisely know the loading at any second through WUG (what's up gold incase you did not know)

I hope that helps in you narrowing your thoughts

Many thanks

John

[Weaver]

@d2d4j - many thanks, John

[d2d4j]

Hi weaver

Many thanks, and to show what I mean, please see the best and worst results, where the below would show DC to DC and dialup.

You will see the download file size is adjusted accordingly, which indicates it has been run in auto mode, as apposed to manual, where the you select the test server and file size for upload/download selected.  Automode, tries to establish the tester connection speed, and would restart the test from a lower file size to a larger file size, depending upon the speed.

The file used is a near uncompresable file, so it attempts to exclude any compression to speed up transfer, and speed is calculated as we did in early days, measure download size over time taken.  However, I cannot comment on other speedtest websites.

Lastly, a mute point, but most people get a little confused over up/down, so the download speed shown is your download speed but our test server upload speed, and upload speed is your upload speed but our test server download speed

I hope that helps a little

Many thanks

John

---------------------------------------------------------------------------------

2207528 kbps down (~2207.53 Mbps, 269474 KB/s) ↓
220 kbps up (~0.22 Mbps, 27 KB/s) ↑

Details:

10240 KB downloaded in 0.038 seconds
4 KB uploaded in 0.149 seconds
Speed @ 15045% of the average for unity-media.net
41651 times faster than 56k dialup
Tested on: 2015.03.04 12:15 EST
Tested from: helweb.co.uk
Test ID: 4335431
Browser/OS: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
IP Address: 37.24.xxx.xxx
Provider: unity-media.net
Location: US

---------------------------------------------------------------------------------

2097152 kbps down (~2097.15 Mbps, 256000 KB/s) ↓
178 kbps up (~0.18 Mbps, 22 KB/s) ↑

Details:

1024 KB downloaded in 0.004 seconds
1024 KB uploaded in 47.135 seconds
Speed @ 498% of the average for dyn.jtglobal.com
39569 times faster than 56k dialup
Tested on: 2015.03.29 11:24 EDT
Tested from: helweb.co.uk
Test ID: 4352281
Browser/OS: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
IP Address: 82.112.xxx.xx
Provider: dyn.jtglobal.com
Location: Saint Helier, JE 

------------------------------------------------------------------------------------

1010676 kbps down (~1010.68 Mbps, 123373 KB/s) ↓
94 kbps up (~0.09 Mbps, 12 KB/s) ↑

Details:

10240 KB downloaded in 0.083 seconds
4 KB uploaded in 0.347 seconds
Speed @ 9984% of the average for pools.vodafone-ip.de
19069 times faster than 56k dialup
Tested on: 2015.05.31 07:13 EDT
Tested from: helweb.co.uk
Test ID: 4382210
Browser/OS: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
IP Address: 188.109.xxx.xxx
Latency: 127ms
Provider: pools.vodafone-ip.de
Location: D�sseldorf, DE 

-------------------------------------------------------------------------------------

6 kbps down (~0.01 Mbps, 1 KB/s) ↓
29 kbps up (~0.03 Mbps, 4 KB/s) ↑

Details:

100 KB downloaded in 138.576 seconds
100 KB uploaded in 27.794 seconds
Speed @ 10% of the average for dial.eltopia.net
Tested on: 2016.01.18 17:29 EST
Tested from: helweb.co.uk
Test ID: 4484305
Browser/OS: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
IP Address: 67.206.xxx.xx
Latency: 644ms
Provider: dial.eltopia.net
Location: Selah, WA, US 

--------------------------------------------------------------------------------------

61 kbps down (~0.06 Mbps, 7 KB/s) ↓
30 kbps up (~0.03 Mbps, 4 KB/s) ↑

Details:

100 KB downloaded in 13.354 seconds
100 KB uploaded in 27.721 seconds
Speed @ 105% of the average for dial.eltopia.net
Tested on: 2016.02.15 16:55 EST
Tested from: helweb.co.uk
Test ID: 4497310
Browser/OS: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
IP Address: 67.206.xxx.xx
Latency: 277ms
Provider: dial.eltopia.net
Location: Selah, WA, US 

---------------------------------------------------------------------------------------

[aesmith]

I mostly come across shaping when we're dealing with a partial bandwidth circuit, eg 10meg bearer with 4meg contracted bandwidth.     In these cases I always shape to the exact figure.  However we're dealing with similar technologies in those cases, so if we shape to the CIR then the service provider policing never needs to drop any of our traffic, and our prioritisation remains effective.

However I guess it would be easy enough for you to try shaping to a touch lower than the upstream speed, and see whether that makes any different to that "ripple".   For what it's worth when I was testing at home it appeared that my upstream rate was 392K at the IP level, if I increased the shaping to 393 then round trip times when through the roof.  That was on a synch speed of 448.  So on my connection I'd be happy that shaping to 392 would mean BTW shouldn't be dropping any of my prioritised packets.

As an aside, I found a simple policy of prioritising small packets was pretty effective, with that single rule both prioritising RTP for voice and also preventing downloads being slowed down by loss of their upstream ACKs.

Tony S

[Weaver]

> However I guess it would be easy enough for you to try shaping to a touch lower than the upstream speed, and see whether that makes any different to that "ripple".

I hope that's what I am already doing in that screen shot as I'm using a fudge factor (multiplication factor to convert bps at the AAL5 SDU level to the PDU level) that I think is slightly low, at 0.88 (rather than 0.9=48/(48+5)), so under-driving the line very slightly..

> As an aside, I found a simple policy of prioritising small packets was pretty effective, with that single rule both prioritising RTP for voice and also preventing downloads being slowed down by loss of their upstream ACKs.

This is RevK's preferred strategy used in my Firebrick router, and he claims it's good enough, I  think it temporarily gets him out of having to write proper posh controllable QoS.