Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.


Filter this topic showing only the reply marked as answer View this topic in a long page with up to 500 replies per page Create new topic
1 | 2 | 3 | 4 | 5 | 6
4939 posts

Uber Geek
+1 received by user: 1366

Trusted

  Reply # 1399392 3-Oct-2015 15:14
Send private message

chrispchikin:
TimA:
chrispchikin:
TimA:
sbiddle: I do hope you update this thread with whether it fixes it or not. I'm still very much of the opinion the issue is likely to be upstream congestion and the configuration of your network, so changing ISPs won't fix the problem if it is the issue.




Steve, he himself 100% proved it was not the bigpipe network at fault.

And I really don't want to play this card
"I am a L3/L4 Network & Security engineer dealing with large enterprise networks on a daily basis"
If your employer saw this thread they would think twice about your position mate - At least if i was your employer i would.


No, I haven't proved it wasn't Bigpipe, what I have proved is that running iperf on a DSL connection kills it, but that will happen on DSL connection.

I would happily show this thread and the statement above to my employer, but if I were you I would leave personal comments such as yours out of this discussion.

And I gave you a free router, so be nice :)


Haha for the banter matey all for the banter.

I ran iperf from my VDSL to a local server just then and i can still browse sweet and stream even tho the connection is flat lining.


So that would suggest an xDSL connection should be able to cope, yet mine doesn't.

I'd be curious to see your sync speed and iperf speed (with UDP).

Would you mind running iperf and a continuous ping to your ISP's DNS server and seeing if iperf kills that?


Its a dog aye, slow as.





4939 posts

Uber Geek
+1 received by user: 1366

Trusted

  Reply # 1399396 3-Oct-2015 15:30
Send private message



Pretty poor test but as you can see it does show slightly degraded response times to trademe but nothing bad at all. Was still streaming 1080p youtube and online radio.

https://cdn.geekzone.co.nz/imagessubs/a70224dcd86d98942b92395f246530e6.jpg







 
 
 
 




113 posts

Master Geek
+1 received by user: 30


  Reply # 1399398 3-Oct-2015 15:35
Send private message

Hmmm, well it trashes my connection with a single PC on 2 different routers...

So that would seem to indicate issues with my connection specifically...

I'll run the iperf test again after ISP change and report back. At least there is a simple indicative test.

403 posts

Ultimate Geek
+1 received by user: 94


  Reply # 1399419 3-Oct-2015 17:23
Send private message

TimA:

Pretty poor test but as you can see it does show slightly degraded response times to trademe but nothing bad at all. Was still streaming 1080p youtube and online radio.

https://cdn.geekzone.co.nz/imagessubs/a70224dcd86d98942b92395f246530e6.jpg




trying some testing myself and I noted that using  " iperf3 -u -c 3.testdebit.info -t 1000"
you are limiting the outbound to 1Mbit (about the limit of your ADSL connection

however both Tim and I are on a VDSL connection with a upstream of around 10Mbit
If you use " iperf3 -u -b0 -c 3.testdebit.info -t 1000"

Click to see full sizeClick to see full size

 

Chug Chug... even my QOS cant handle that!




 The views expressed by me are not necessarily those of my employer


2240 posts

Uber Geek
+1 received by user: 352

Trusted
Subscriber

  Reply # 1399438 3-Oct-2015 18:47
Send private message

chrispchikin: 

...
PING 210.54.35.129: 56  data bytes, press CTRL_C to break
    Request time out
    Reply from 210.54.35.129: bytes=56 Sequence=1 ttl=255 time=1455 ms
    Reply from 210.54.35.129: bytes=56 Sequence=2 ttl=255 time=238 ms
    Reply from 210.54.35.129: bytes=56 Sequence=3 ttl=255 time=364 ms
    Reply from 210.54.35.129: bytes=56 Sequence=4 ttl=255 time=762 ms

...


Have you monitored the modem's inside interface at the same time as their BRAS or their DNS servers? Just interested to know whether you're still getting good fast responses back? 

I know the Draytek is an OK modem, however I recall needing to hard set the WAN interface's MTU to 1500 manually, else you'd end up with all manner of nastiness. 





122 posts

Master Geek
+1 received by user: 96

Trusted
BigPipe

  Reply # 1399444 3-Oct-2015 18:59
Send private message

chrispchikin: I've been made an offer I can't refuse from a friend's ISP, as such I'll be requesting a disconnection from Bigpipe.

Thanks for all of your help Bigpipe, took a bit of pressure but in the end you really came to the party and provided information in a public forum.


Happy to help! Best of luck with your new ISP. Hope the new connection works out well. 




www.bigpipe.co.nz

 

https://www.facebook.com/BigPipeNZ

 

https://twitter.com/BigPipeNZ

 


550 posts

Ultimate Geek
+1 received by user: 141


  Reply # 1399447 3-Oct-2015 19:27
Send private message

One last thing to try.

Try forcing the modem in to ITU G.992.1     ADSL (G.dmt)

I know this will slow your connection down, There was an issue a few years ago with Chorus gear and some chipsets

This is what we had to do to resolve the issue.

I hope it helps.

best of luck.

John




I know enough to be dangerous


'That VDSL Cat'
6171 posts

Uber Geek
+1 received by user: 1157

Trusted
Spark
Subscriber

  Reply # 1399450 3-Oct-2015 19:33
2 people support this post
Send private message

Do remember VDSL vs ADSL is not a fair comparasion for upstream congestion.

10mbit is 10 times as much wiggle room to still get the ICMP packets out and back nice and rapidly.


a basic home user router often does preform its own QOS, to a point. try doing this test with such a modem, then bridge and do it directly with your computer terminating the PPP session. - For the point of this thread, i do not see the point in proving this to you. You have already shown your own setup is the root cause of your issue.

Saturation will always cause spikes and jitter. on a smaller pipe, it is easier to saturate. With a 1mbit upstream more than about half of what will start affective traffic be it spontaneous spikes before dipping back to normal.

To give you an example, here is a snap of my RRD graphs for one of my connections.




Do remember to note, this is a RRD Graph, and is averaged per minute.

You will probably note that theres a pretty obvious cap point at about 500kbit on the upstream. This is where Large heavy streams are shapped. (Dropbox, seeding etc)

I wont embedd the images of the queues but https://i.imgur.com/EwOKIA0.png  https://i.imgur.com/x0Dv90q.png Without those queues controlling the packets, latencies easily fly.

Heres a very quick test without QOS however - Cavet in this testing is i have no removed other usage within house.

First test with QOS all off, the second with it on. a reduction of 46 kbit was seen between shaped and unshaped. the second test does see a spike towards the end although rather minor compared to without shaping, That was downstream traffic (and the cosponsoring TCP Acks joining in the queues.) of other users.

This was a Single threaded 30 second TCP iperf run to my personal server in LA. obviously multiple threads, would cause more strain.

>ping google.co.nz -t

Pinging google.co.nz [203.118.143.217] with 32 bytes of data:
Reply from 203.118.143.217: bytes=32 time=8ms TTL=61
Reply from 203.118.143.217: bytes=32 time=7ms TTL=61
Reply from 203.118.143.217: bytes=32 time=7ms TTL=61
Reply from 203.118.143.217: bytes=32 time=8ms TTL=61
Reply from 203.118.143.217: bytes=32 time=351ms TTL=61
Reply from 203.118.143.217: bytes=32 time=488ms TTL=61
Reply from 203.118.143.217: bytes=32 time=455ms TTL=61
Reply from 203.118.143.217: bytes=32 time=470ms TTL=61
Reply from 203.118.143.217: bytes=32 time=460ms TTL=61
Reply from 203.118.143.217: bytes=32 time=479ms TTL=61
Reply from 203.118.143.217: bytes=32 time=469ms TTL=61
Reply from 203.118.143.217: bytes=32 time=518ms TTL=61
Reply from 203.118.143.217: bytes=32 time=480ms TTL=61
Reply from 203.118.143.217: bytes=32 time=478ms TTL=61
Reply from 203.118.143.217: bytes=32 time=478ms TTL=61
Reply from 203.118.143.217: bytes=32 time=479ms TTL=61
Reply from 203.118.143.217: bytes=32 time=508ms TTL=61
Reply from 203.118.143.217: bytes=32 time=466ms TTL=61
Reply from 203.118.143.217: bytes=32 time=492ms TTL=61
Reply from 203.118.143.217: bytes=32 time=474ms TTL=61
Reply from 203.118.143.217: bytes=32 time=462ms TTL=61
Reply from 203.118.143.217: bytes=32 time=473ms TTL=61
Reply from 203.118.143.217: bytes=32 time=465ms TTL=61
Reply from 203.118.143.217: bytes=32 time=450ms TTL=61
Reply from 203.118.143.217: bytes=32 time=482ms TTL=61
Reply from 203.118.143.217: bytes=32 time=461ms TTL=61
Reply from 203.118.143.217: bytes=32 time=455ms TTL=61
Reply from 203.118.143.217: bytes=32 time=454ms TTL=61
Reply from 203.118.143.217: bytes=32 time=467ms TTL=61
Reply from 203.118.143.217: bytes=32 time=491ms TTL=61
Reply from 203.118.143.217: bytes=32 time=497ms TTL=61
Reply from 203.118.143.217: bytes=32 time=473ms TTL=61
Reply from 203.118.143.217: bytes=32 time=472ms TTL=61
Reply from 203.118.143.217: bytes=32 time=476ms TTL=61
Reply from 203.118.143.217: bytes=32 time=138ms TTL=61
Reply from 203.118.143.217: bytes=32 time=8ms TTL=61
Reply from 203.118.143.217: bytes=32 time=8ms TTL=61
Reply from 203.118.143.217: bytes=32 time=8ms TTL=61
Reply from 203.118.143.217: bytes=32 time=8ms TTL=61
Reply from 203.118.143.217: bytes=32 time=8ms TTL=61
Reply from 203.118.143.217: bytes=32 time=8ms TTL=61
Reply from 203.118.143.217: bytes=32 time=7ms TTL=61
Reply from 203.118.143.217: bytes=32 time=7ms TTL=61
Reply from 203.118.143.217: bytes=32 time=7ms TTL=61

Ping statistics for 203.118.143.217:
Packets: Sent = 44, Received = 44, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 518ms, Average = 326ms

>ping google.co.nz -t

Pinging google.co.nz [203.118.143.217] with 32 bytes of data:
Reply from 203.118.143.217: bytes=32 time=7ms TTL=61
Reply from 203.118.143.217: bytes=32 time=18ms TTL=61
Reply from 203.118.143.217: bytes=32 time=34ms TTL=61
Reply from 203.118.143.217: bytes=32 time=7ms TTL=61
Reply from 203.118.143.217: bytes=32 time=41ms TTL=61
Reply from 203.118.143.217: bytes=32 time=71ms TTL=61
Reply from 203.118.143.217: bytes=32 time=57ms TTL=61
Reply from 203.118.143.217: bytes=32 time=46ms TTL=61
Reply from 203.118.143.217: bytes=32 time=25ms TTL=61
Reply from 203.118.143.217: bytes=32 time=9ms TTL=61
Reply from 203.118.143.217: bytes=32 time=59ms TTL=61
Reply from 203.118.143.217: bytes=32 time=24ms TTL=61
Reply from 203.118.143.217: bytes=32 time=28ms TTL=61
Reply from 203.118.143.217: bytes=32 time=16ms TTL=61
Reply from 203.118.143.217: bytes=32 time=21ms TTL=61
Reply from 203.118.143.217: bytes=32 time=17ms TTL=61
Reply from 203.118.143.217: bytes=32 time=43ms TTL=61
Reply from 203.118.143.217: bytes=32 time=67ms TTL=61
Reply from 203.118.143.217: bytes=32 time=66ms TTL=61
Reply from 203.118.143.217: bytes=32 time=159ms TTL=61
Reply from 203.118.143.217: bytes=32 time=229ms TTL=61
Reply from 203.118.143.217: bytes=32 time=153ms TTL=61
Reply from 203.118.143.217: bytes=32 time=210ms TTL=61
Reply from 203.118.143.217: bytes=32 time=201ms TTL=61
Reply from 203.118.143.217: bytes=32 time=204ms TTL=61
Reply from 203.118.143.217: bytes=32 time=177ms TTL=61
Reply from 203.118.143.217: bytes=32 time=172ms TTL=61
Reply from 203.118.143.217: bytes=32 time=154ms TTL=61
Reply from 203.118.143.217: bytes=32 time=140ms TTL=61
Reply from 203.118.143.217: bytes=32 time=174ms TTL=61
Reply from 203.118.143.217: bytes=32 time=164ms TTL=61
Reply from 203.118.143.217: bytes=32 time=147ms TTL=61
Reply from 203.118.143.217: bytes=32 time=127ms TTL=61
Reply from 203.118.143.217: bytes=32 time=178ms TTL=61
Reply from 203.118.143.217: bytes=32 time=220ms TTL=61
Reply from 203.118.143.217: bytes=32 time=60ms TTL=61
Reply from 203.118.143.217: bytes=32 time=10ms TTL=61
Reply from 203.118.143.217: bytes=32 time=8ms TTL=61
Reply from 203.118.143.217: bytes=32 time=7ms TTL=61
Reply from 203.118.143.217: bytes=32 time=8ms TTL=61
Reply from 203.118.143.217: bytes=32 time=8ms TTL=61
Reply from 203.118.143.217: bytes=32 time=46ms TTL=61

Ping statistics for 203.118.143.217:
Packets: Sent = 42, Received = 42, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 229ms, Average = 86ms



To detail my setup, encase your interested in direct comparisons Pfsense runs on a Esxi HV (realtek compatibility is iffy without the wrapper.) connecting through a TG582n in bridge mode, using a PPPoE session over VLAN 10, Vodafone as an ISP (overhead a welcomed cost for getting rid of the instability of raw DHCP over VLAN10.)

No two modems preform EXACTLY the same, do remember that. it doesn't matter if your modem costs 20$ or 2000$ its configuration can make a massive difference. I understand you have plenty of experience in networking But here, You are mistaken Sorry. Your not seeing an issue on the DSL interface, BP are simply acting as an isp, passing on the packets... The issue is within your setup.
You have a 1mbit upstream, to take the road analogy, that is easy to get into gridlock.

Your picking out errors out of your modem without considering the error message "defragmented", What happens when a crc error occurs? (even on the best of lines, you will see them occasionally...) ofcourse your going to see a fragmented packet! atlest one has been lost.




#include <std_disclaimer>

 

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.




113 posts

Master Geek
+1 received by user: 30


  Reply # 1399474 3-Oct-2015 21:01
Send private message

How have I proved that it is my own setup?

517 posts

Ultimate Geek
+1 received by user: 133


  Reply # 1399480 3-Oct-2015 21:07
2 people support this post
Send private message

chrispchikin: How have I proved that it is my own setup?

 

By flooding your upstream with the DV120 and having a usable connection still, it seems to imply that QoS on the DV120 is managing things correctly.

 

 

Give it a go with your HP, and see if you get the same results, just to prove it does or doesn't also work when flooded like that.



113 posts

Master Geek
+1 received by user: 30


  Reply # 1399483 3-Oct-2015 21:24
Send private message

toejam316:
chrispchikin: How have I proved that it is my own setup?

By flooding your upstream with the DV120 and having a usable connection still, it seems to imply that QoS on the DV120 is managing things correctly.

Give it a go with your HP, and see if you get the same results, just to prove it does or doesn't also work when flooded like that.


Ok, I appreciate some of the clarity may have been lost but I have already done the same test with the HP and actually had better results than with the DV120.

ICMP requests would simply time out with the DV120 and a single PC, whereas the HP would still receive a fair amount,with a very high latency.

And that is with iperf.

with a more 'real world' scenario with both routers, streaming Netflix, while uploading to Google Drive and pushing ~900k I could still browse the web comfortably, I.e. Couldn't replicate the fault saturating the upstream with real world traffic scenarios.

Please keep in mind that usage habits have not changed in our small household when the issue started, config hasn't changed and the issue originally began as hard disconnects (which I believe we're resolved by Chorus earlier this month, by repairing cabling at the exchange and our ETP). The instability however still continues.



6608 posts

Uber Geek
+1 received by user: 2083

Subscriber

  Reply # 1405226 13-Oct-2015 20:53
One person supports this post
Send private message

right, where do you stand now?



113 posts

Master Geek
+1 received by user: 30


  Reply # 1405250 13-Oct-2015 21:22
Send private message

New ISP, new port presumably (1-1.5Mbps better sync, was processed as a disconnection / new connection by Chorus). Same router, same config.

No issues, happy me, happy family.

6608 posts

Uber Geek
+1 received by user: 2083

Subscriber

  Reply # 1405582 14-Oct-2015 11:24
Send private message

so you still dont know what the issue was



113 posts

Master Geek
+1 received by user: 30


  Reply # 1405583 14-Oct-2015 11:26
Send private message

Jase2985: so you still dont know what the issue was


I have my suspicions, but for the purposes of Geekzone I'm just happy its working now.

1 | 2 | 3 | 4 | 5 | 6
Filter this topic showing only the reply marked as answer View this topic in a long page with up to 500 replies per page Create new topic



Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:





News »

IDC thinks ANZ is a nation
Posted 27-Jul-2017 11:51


British new home buyers see ultrafast broadband as vital
Posted 27-Jul-2017 09:46


Australians want NZ-style gigabit, but for less
Posted 27-Jul-2017 08:57


Push notifications: A productivity killer
Posted 25-Jul-2017 14:15


Intergen takes SKYCITY to the cloud
Posted 25-Jul-2017 14:04


Nothing nebulous about Microsoft’s cloud-transition
Posted 21-Jul-2017 15:34


We’re spending more on tech, but not as much as Australians
Posted 21-Jul-2017 11:43


Endace announces EndaceFabric for network-wide packet recording
Posted 20-Jul-2017 20:49


Acorn 6: MacOS image editing for the rest of us
Posted 20-Jul-2017 17:04


HTC faces backlash over keyboard pop-up ads
Posted 19-Jul-2017 15:53


BNZ adds Visa credit cards to Android Pay wallet
Posted 18-Jul-2017 19:44


Still living in a Notification hell – Om Malik
Posted 18-Jul-2017 13:00


Duet Display uses iPad to extend Mac, PC
Posted 18-Jul-2017 10:58


PC sales could be worse
Posted 17-Jul-2017 07:34


Crypto-currencies, tulips, market bubbles
Posted 17-Jul-2017 06:38



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.