Regular nightly LUS Fiber speed slow-downs?

[Robert]

I did not anticipate significant slowing of download and upload speeds
on my LUS fiber to the home, which is known to be common with cable
internet. Every night, at around 8 to 10pm, my purchased 50Mbps
download speed slows to 3 to 6 Mbps! Upload speeds also severely
crippled. My home network is highly secured and I am the only one
online at my home. No other programs or network access activity are
running on my computer. Can anyone else confirm that their own
internet speeds are also dramatically slower with LUS Fiber in the
evenings? It's not just the extranet, even the tested LUS intranet
speeds are much slower! This sure appears like severe LUS network
congestion, but come on, this seems unbelievable to me. Tomorrow
morning I'll be downloading at 47 or 48 Mbps! Seriously. Is anyone
else seeing this?

[Kyle Pinkley]

Actually this happens to me as well. At night I'll get 3.2mbps then during the day and during the day I can pull 5.4mbps which is normal. Probably started a month ago.

Sent from my phone. Please excuse any errors.

> --
> You received this message because you are subscribed to the Google Groups "Lafayette Technology" group.
> To post to this group, send email to lafaye...@googlegroups.com.
> To unsubscribe from this group, send email to lafayettetec...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lafayettetech?hl=en.
>

[Bryan Fuselier]

This is the result of shared connectivity. Cox/at&t do it as well. Difference is Cox will deliver shared to the node. LUS delivers shared to the city. If you buy 15 mbps from cox, that 15 is shared with a few neighborhoods around you. With LUS, you just need a few hogs in the city. They are not limiting/capping each subscriber so there is nothing that can be done to prevent it right now. As far as I'm aware.

This is why businesses that require good connections during all times of day can and should buy dedicated bandwidth.

[Kyle Pinkley]

I'm okay with it coming from Cox.   Speeds were horrid all the time with Cox even having DOCSIS3 (rep told me node was overloaded all the time).

Sent from my phone.  Please excuse any errors.

[John St. Julien]

All, 

Why don't we get together and see if there really is a regular, repeatable issue? I haven't tested my link in a long time but see that Ookla/Speedtest has recently launched a revamp of its service that improves it in several ways. Among those improvements is what they call a "wave" which is a way to share the record of a series of speed tests and share them among users. We could share a series of tests of LUS and see if there is actually a problem and, if so, how widespread.

I've started the wave...at 8:08 tonight:

http://www.speedtest.net/wave/c56cc7784bc65f20

I'd encourage anyone to repeat the test at any time and contribute to the wave. But we are especially interested in the 8-10 pm slot where Robert has seen slowdowns. Kyle also sees nigh time slowdowns.

Conditions for consistency: 

1) Please use the Hammond Server. it's closest

2) Connect directly to the LUS Ethernet wire that comes out of the wall, do NOT use an ethernet connection or stand behind a router. (I and I think most people's LAN is slower than the LUS WAN.)

Limitations: I don't see any way to notate the speed tier we are in. I bought the 50/50 meg tier and so was pleased and puzzled. I was pleased when my initial test tonight showed 93 down and puzzled by the 17 up. Actually I'm puzzled by both. :-) Didn't expect more than 50...

We could leave notes here I guess as to what tier we have if that turns out to make a difference. 

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

I don't think regular congestion-type problems should be happening on our network...The system capacity is so large, the user nodes so small that in-system congestion should just not be happening. It doesn't, as Bryan implies, seem likely that any problem is the usual local congestion given the quality of our local system.

Byran suggests (I think) that it might be connection to the larger internet--at the "edge" of our network and that we don't have a large enough connect to the greater internet. But it's difficult for me to credit that a few users could saturate that connection for long or that such a saturation, if it occurs, would happen systematically at the same time each day. More, we are all constrained/throttled in our connection to the larger internet—that's where the 50 to 10 meg tiers come in. True, LUS is not likely buying enough bandwidth to let us all use our max allowance ALL the time. That'd never happen and buying that much would be wasteful. Oversubscription is a reasonable thing to keep costs down But if a pattern _is_ occurring where folks can't get the bandwidth they've paid for then that would be the signal that we've underbought.  

John St. Julien

The best way to predict the future is to invent it. --Alan Kay

blog.lafayetteprofiber.com/

Supporting Fiber To The Home in Lafayette, Louisiana

[Robert]

John- that's a good idea! I submitted a few tests tonight to the
Speedtest.net "wave" this evening that weren't bad, all things
considered, but they were nowhere near as good as your download
speeds. You may have paid for 50Mbps service, but I think LUS may have
flipped "on" your 100Mbps switch! Maybe no one else has signed up for
LUS Fiber in your neighborhood! When I tested my speeds at the LUS
Fiber speed test site (extranet), my numbers were horrible (2.3Mbps
download!), despite having the 50Mbps service. The Speakeasy testing
site (using Dallas) also returned horrible download speeds for me.
Atlanta was much better. Must be something wrong with the LUS Fiber
testing site and the normally fast Dallas sever- but only at night-
does this suggest major server traffic and congestion at these sites
to the West at night?

[John St. Julien]

Hi Robert, 

I've no idea why my numbers look so good, the down ones anyway...When I last tested at least a year ago my numbers hovered around 50. And often my upload was actually faster than my download. They looked more like your numbers...which are decent for the 50 meg tier.

One thing that makes a huge difference for me is hooking up directly to the LUS wire that comes out of the wall. I take my router completely out of the picture. I have an dual mode B/G-N wifi node/router and have chosen one that did well various tests with high speed connectivity (lots of them simply can't handle incoming/wan speeds of 30 megs or more). Even so I clearly need to do some tweaking on my router.

If you are not getting the speeds you should on LUS' test you should contact LUS. I presume they've got lots of analytics sitting behind the part they expose to users that could be helpful.

Re your remarks on servers: One big factor that you'll find in the various freely available, internet-based test suites is that the routing makes a huge difference. There can be persistent problems at one server along the way. (At one point LUS told me that a specific AT&T node that they were connecting to had bad problems.) However, in general, each jump the message takes eats up time; the fewer "jumps" it takes to get to the testing server the faster connection you will get. So, all things being equal, the "nearer" you are topologically--which only roughly corresponds to physically--the more consistent your numbers will be. (That's why i chose the closest server to Lafayette as the baseline for the wave.) Not sure what could be going on in Dallas...It's always possible that something systematic is happening there or at a link to Dallas in the evenings...hard to say.

John

--
You received this message because you are subscribed to the Google Groups "Lafayette Technology" group.
To post to this group, send email to lafaye...@googlegroups.com.
To unsubscribe from this group, send email to lafayettetec...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lafayettetech?hl=en.

[Dane DeValcourt]

The proximity to a physical location is not always the best choice IMHO.  You will often find that the actual path to things locally will first go out to Dallas or some other peering point before making it's way back to say a server in Hammond.

If the test doesn't reveal the IP of the testing server then I'd sniff a test to a few different servers and capture some IPs.  Then traceroute to them and confirm the actual path and hops taken.

Depending on who LUS is peering with will impact your route / path to various sites.

On Cox the Dallas server tends to give best results since that's a major peering point, most traffic to the net from Cox will go through Dallas regardless.  Obviously the New Orleans test yields good results on Cox but it's a Cox server so I don't think it's a fair or accurate test for others.

A LUS customer trying to test with say the Cox New Orleans server is likely going to go through Dallas then to New Orleans.  So in that case it would make more sense to just text against the Dallas server.

Just a thought.

[John St. Julien]

Hi Dane,

All you say makes good sense...If I was being really rigorous I'd test the more likely servers and paths over a series of days to make sure that Hammond really closest topologically...but seeing as how I was lazy I just decided to go with easy method of getting a common server to standardize on. 

It might not yield the fastest path but, hopefully, it will be serve well enough to spot a consistent slowdown. If we find one we can tracer route and get more sophisticated to make sure the issue not in an interim place.

John 

[Robert]

John, thanks for your help. Dane, your comments probably explain why
when I'm on the Speedtest.net site, if I let the Speedtest program
determine my "best" server (based on ping time), it will choose either
Dallas- or interestingly enough- last night it was Temple, TX. I had
a ping time of 24 ms to Temple, much quicker than the ping of 120 ms
to Hammond, LA. This suggests that we are likely routed elsewhere
first before jumping along to Hammond, despite its closer proximity to
Lafayette. The LUS Fiber "intranet" speed test site (http://
speed.lusfiber.net:81/) routes to Hammond though, and this is intended
to show the speed of downloads and uploads on the fiber ring. How can
this be so, if it leaves our local Lafayette ring and transfers data
to Hammond for the test? I guess it never leaves fiber lines to the
Internet servers.

I've contacted Ryan Meche, one of the tech support team members at LUS
fiber. He said they have begun investigating this issue of potential
night time slow downs in the network, and when they are done capturing
and analyzing the network data, they will update us on their findings.
Ryan asked that anyone who feels that they are experiencing this issue
to create a ticket with the LUS technical support team (phone number:
99-Fiber). He said this will allow them to trend what is going on and
get a better understanding of how widespread the issue is. Ryan also
thanked us for being proactive LUS fiber customers, as any and all
info they receive from us will assist them in their troubleshooting
efforts. He says that he will join the Lafayette Technology Google
Group so that he can monitor the conversation and review our
Pingtest.net "Wave" results. Kudos to Ryan.

Robert

On Mar 14, 12:41 pm, Dane DeValcourt <dane.devalco...@gmail.com>
wrote:

> The proximity to a physical location is not always the best choice IMHO.  You will often find that the actual path to things locally will first go out to Dallas or some other peering point before making it's way back to say a server in Hammond.
>
> If the test doesn't reveal the IP of the testing server then I'd sniff a test to a few different servers and capture some IPs.  Then traceroute to them and confirm the actual path and hops taken.
>
> Depending on who LUS is peering with will impact your route / path to various sites.
>
> On Cox the Dallas server tends to give best results since that's a major peering point, most traffic to the net from Cox will go through Dallas regardless.  Obviously the New Orleans test yields good results on Cox but it's a Cox server so I don't think it's a fair or accurate test for others.
>
> A LUS customer trying to test with say the Cox New Orleans server is likely going to go through Dallas then to New Orleans.  So in that case it would make more sense to just text against the Dallas server.
>
> Just a thought.
>

> >> For more options, visit this group athttp://groups.google.com/group/lafayettetech?hl=en.

[Bryan Fuselier]

Robert,

I can guarantee that the test server at speedtest.lusnet.net is definitely on the LUS intranet. If you are experiencing slow connections to it, LUS has an intranet congestion/latency issue.

LUS reps already watch this list as one of several ways to detect issues. I'm sure they're working diligently to get it resolved.

Thanks,
Bryan F.

[Dane DeValcourt]

Well I just did a capture to determine more info on the Hammond server.

I captured 207.29.218.115

According to ARIN whois this belongs to Hunt Brothers and corresponds to what Speedtest.net says is the sponsor:

http://whois.arin.net/rest/net/NET-207-29-208-0-1/pft

Here is their network map from their website:

http://www.hunttelecom.com/images/networkmap-17january2008revision2-cbs.gif

My tracert (I'm on Cox however) shows me hitting Dallas and hoping on to tinet.net which continues over to them.

  5 - I leave Cox at this hop

  6    94 ms    88 ms   123 ms  xe-3-0-0.dal33.ip4.tinet.net [89.149.183.53]

  7    91 ms    88 ms    91 ms  hunt-brothers-of-louisiana.ip4.tinet.net [77.67.71.226]

  8   108 ms   110 ms   106 ms  72.20.191.129

  9   107 ms   107 ms   107 ms  www3.huntbrothers.com [207.29.218.115]

Their AS is 32592

Their peering info is:

http://www.robtex.com/as/as32592.html#peer

Now on the LUS side I see that speed.lusfiber.net resolves to 74.80.40.9

This is an LUS address:  http://whois.arin.net/rest/net/NET-74-80-0-0-1/pft

LUS AS is 25921

Their peers are:

http://www.robtex.com/as/as25921.html#graph

Basically AT&T and QWest it would seem.

I'd be interested in someone on LUS fiber doing a tracert to the Hammond server (207.29.218.115) and sharing the results.  I'm very curious as to the path since according to the Hunt Brothers map there is a DS3 link shown between Lafayette and Hammond but it doesn't detail anything as to what DS3 that is with.

Hope thats helpful or interesting at least.

Regards,
Dane

[Bryan Fuselier]

here you go...right after it leaves my router then  it basically times out after this. but the last ip is owned by Hunt

3  76-72-16-2.PHK.stat.lusfiber.net (76.72.16.2)  7.329 ms  6.913 ms  7.470 ms

 4  * * *

 5  iah-edge-05.inet.qwest.net (67.135.15.245)  10.964 ms  11.083 ms  11.207 ms

 6  dap-brdr-03.inet.qwest.net (67.14.2.89)  60.832 ms  12.097 ms  12.720 ms

 7  63.146.27.126 (63.146.27.126)  16.864 ms  16.989 ms  16.681 ms

 8  0.ae1.XL4.DFW7.ALTER.NET (152.63.96.86)  17.488 ms  17.348 ms  17.085 ms

 9  POS7-0.GW1.DFW13.ALTER.NET (152.63.103.89)  19.694 ms  19.675 ms  19.673 ms

10  hbcorporate-gw.customer.alter.net (63.65.120.250)  19.977 ms  20.505 ms  19.797 ms

11  72.20.191.129 (72.20.191.129)  62.352 ms  62.593 ms  57.607 ms

[Tim Fournet]

We had a customer in town that kept complaining about bad speed tests on his 50 meg cox connection. When I took a look at it he had been using that Hunt ISP to test against. Once I had him test against a dallas or atlanta connection, he started getting results that were much closer to what he expected.

On Mar 15, 2011 10:13 AM, "Bryan Fuselier" <digerat...@gmail.com> wrote:

here you go...right after it leaves my router then  it basically times out after this. but the last ip is owned by Hunt

3  76-72-16-2.PHK.stat.lusfiber.net (76.72.16.2)  7.329 ms  6.913 ms  7.470 ms

 4  * * *

 5  iah-edge-05.inet.qwest.net (67.135.15.245)  10.964 ms  11.083 ms  11.207 ms

 6  dap-brdr-03.inet.qwest.net (67.14.2.89)  60.832 ms  12.097 ms  12.720 ms

 7  63.146.27.126 (63.146.27.126)  16.864 ms  16.989 ms  16.681 ms

 8  0.ae1.XL4.DFW7.ALTER.NET (152.63.96.86)  17.488 ms  17.348 ms  17.085 ms

 9  POS7-0.GW1.DFW13.ALTER.NET (152.63.103.89)  19.694 ms  19.675 ms  19.673 ms

10  hbcorporate-gw.customer.alter.net (63.65.120.250)  19.977 ms  20.505 ms  19.797 ms

11  72.20.191.129 (72.20.191.129)  62.352 ms  62.593 ms  57.607 ms

On Mon, Mar 14, 2011 at 7:03 PM, Dane DeValcourt <dane.de...@gmail.com> wrote:
>

> Well I ju...

--

You received this message because you are subscribed to the Google Groups "Lafayette Technology" gro...

[Dane DeValcourt]

Well there ya have it. Even from LUS it's going to Dallas via Qwest then to the HB.

I don't recommend using the HB server, I'd just use Dallas if it was me.

[Bryan Fuselier]

As a wholesaler, we get maintenance notifications from the LUS NOC. Last night they performed a maintenance with the reason:

Purpose:	Reset Core network equipment to induce load balancing
Summary:	To ensure network traffic across both LUS Fiber Internet vendors is load balanced to increase efficiency and reduce congestion

This happened last night at midnight. Things should be better now.

[Robert]

Thanks Bryan. I'll test again tonight. I wonder if it's possible to
run a capture/tracer of the site that LUS Fiber provides for testing
Internet speeds. Where is this one routed, and why does this LUS site
indicate much faster upload speeds than Speedtest.net?

http://speedtest.lusnet.net/

I wonder who LUS has contracted with for speed testing, and how it's
routed there? This LUS speedtest site not only consistently indicates
higher download speeds, but much higher upload speeds, which would
support the expected symmetrical service up and down. But...the
upload speeds are consistently much lower on all other Internet speed
testing sites- the most reputable probably being Speedtest.net. I'm
curious about this. The trend thus-far on the limited 'wave' results
is showing non-symmetrical and much slower upload speeds. Someone on
AT&T posted very nice speeds (particularly upload) to our wave.

I'm happy- just curious :)

Robert

On Mar 16, 8:49 am, Bryan Fuselier <digerati.sen...@gmail.com> wrote:
> As a wholesaler, we get maintenance notifications from the LUS NOC. Last
> night they performed a maintenance with the reason:
>

> *Purpose:***
>
> *Reset Core network equipment to induce load balancing  ***
>
> *Summary:***
>
> *To ensure network traffic across both LUS Fiber Internet vendors is load
> balanced to increase efficiency and reduce congestion*

>
> This happened last night at midnight. Things should be better now.
>

> On Tue, Mar 15, 2011 at 11:21 AM, Dane DeValcourt <dane.devalco...@gmail.com

>
>
>
>
>
>
>
> > wrote:
> > Well there ya have it. Even from LUS it's going to Dallas via Qwest then to
> > the HB.
>
> > I don't recommend using the HB server, I'd just use Dallas if it was me.
>

> > On Mar 15, 2011, at 10:13 AM, Bryan Fuselier <digerati.sen...@gmail.com>

> > wrote:
>
> > here you go...right after it leaves my router then  it basically times out
> > after this. but the last ip is owned by Hunt
>
> > 3  76-72-16-2.PHK.stat.lusfiber.net (76.72.16.2)  7.329 ms  6.913 ms
> >  7.470 ms
> >  4  * * *

> >  5   <http://iah-edge-05.inet.qwest.net>iah-edge-05.inet.qwest.net

> > (67.135.15.245)  10.964 ms  11.083 ms  11.207 ms

> >  6   <http://dap-brdr-03.inet.qwest.net>dap-brdr-03.inet.qwest.net(67.14.2.89)  60.832 ms  12.097 ms  12.720 ms

> >  7  63.146.27.126 (63.146.27.126)  16.864 ms  16.989 ms  16.681 ms
> >  8  0.ae1.XL4.DFW7.ALTER.NET (152.63.96.86)  17.488 ms  17.348 ms  17.085
> > ms
> >  9  POS7-0.GW1.DFW13.ALTER.NET (152.63.103.89)  19.694 ms  19.675 ms
> >  19.673 ms

> > 10   <http://hbcorporate-gw.customer.alter.net>

> > hbcorporate-gw.customer.alter.net (63.65.120.250)  19.977 ms  20.505 ms
> >  19.797 ms
> > 11  72.20.191.129 (72.20.191.129)  62.352 ms  62.593 ms  57.607 ms
>

> > On Mon, Mar 14, 2011 at 7:03 PM, Dane DeValcourt <<dane.devalco...@gmail.com>
> > dane.devalco...@gmail.com> wrote:
>
> >> Well I just did a capture to determine more info on the Hammond server.
>
> >> I captured 207.29.218.115
>
> >> According to ARIN whois this belongs to Hunt Brothers and corresponds to
> >> what Speedtest.net says is the sponsor:
>
> >> <http://whois.arin.net/rest/net/NET-207-29-208-0-1/pft>

> >>http://whois.arin.net/rest/net/NET-<207-29-208-0-1>207-29-208-0-1/pft

>
> >> Here is their network map from their website:
>

> >> <http://www.hunttelecom.com/images/networkmap-17january2008revision2-c...>
> >>http://www.hunttelecom.com/images/networkmap-17january2008revision2-c...

>
> >> My tracert (I'm on Cox however) shows me hitting Dallas and hoping on to

> >> <http://tinet.net>tinet.net which continues over to them.

>
> >>   5 - I leave Cox at this hop
> >>   6    94 ms    88 ms   123 ms  xe-3-0-0.dal33.ip4.tinet.net[89.149.183.53]

> >>   7    91 ms    88 ms    91 ms  <http://hunt-brothers-of-louisiana.ip4.tinet.net>

> >> hunt-brothers-of-louisiana.ip4.tinet.net [77.67.71.226]
> >>   8   108 ms   110 ms   106 ms  72.20.191.129

> >>   9   107 ms   107 ms   107 ms   <http://www3.huntbrothers.com>

> >> www3.huntbrothers.com [207.29.218.115]
>
> >> Their AS is 32592
>
> >> Their peering info is:
>
> >> <http://www.robtex.com/as/as32592.html#peer>
> >>http://www.robtex.com/as/as32592.html#peer
>

> >> Now on the LUS side I see that <http://speed.lusfiber.net>

> >> speed.lusfiber.net resolves to 74.80.40.9
>
> >> This is an LUS address:  <http://whois.arin.net/rest/net/NET-74-80-0-0-1/pft>
> >>http://whois.arin.net/rest/net/NET-74-80-0-0-1/pft
>
> >> LUS AS is 25921
>
> >> Their peers are:
>
> >> <http://www.robtex.com/as/as25921.html#graph>
> >>http://www.robtex.com/as/as25921.html#graph
>
> >> Basically AT&T and QWest it would seem.
>
> >> I'd be interested in someone on LUS fiber doing a tracert to the Hammond
> >> server (207.29.218.115) and sharing the results.  I'm very curious as to the
> >> path since according to the Hunt Brothers map there is a DS3 link shown
> >> between Lafayette and Hammond but it doesn't detail anything as to what DS3
> >> that is with.
>
> >> Hope thats helpful or interesting at least.
>
> >> Regards,
> >> Dane
>

> ...
>
> read more »

[Bryan Fuselier]

LUS does not contract the speed test. They built the speedtest server themselves using a third party software. I helped them install it. The server is sitting at a substation on the local intranet.

The results are different due to internet congestion. Once you test against anything outside of the LUS intranet, you are bound to the limitations of the connections from that point out. When testing on http://speedtest.lusnet.net you will get true results for intranet speeds. Once it hits Qwest/AT&T, you're at the mercy of a large portion of internet users in the tri-state area. Chances are, the much slower upload speeds are a result of the test point not being able to handle 50 Mbps back to you. Keep in mind, until the last year or so, 99.99% of people hitting these test servers were testing 15/1.5 type connections. MOST of these test servers are probably on 1 Gbps connections. 10 LUS subscribers with 100 Mbps would bring it to it's knees if they all tested simultaneously. Considering the millions of people online at night, it's a good possibility the connections surrounding these test servers are hit pretty hard on a regular basis.

Run the LUS speedtest again. After it's done, click the Graph tab on the left side of the chart. Click "Click here for detailed analysis". On the resulting page, after the second graphic, there will be an option to download your results in text format.

--

[Dane DeValcourt]

The LUS site is hosted locally on LUSs network which is why you get great speeds to it. It's not indicative however of speeds to the Internet itself since you don't actually leave the LUS network like you would to other speediest sites. It's a good measure though to know both. If you have issues locally then you will likely also have issues further up the path. It would be a great measure for the 100mb intranet and would show if maybe you have problems with your own gear.

It's been mentioned before that one of the greatest challenges with the higher speeds providers are now able to provide is limitations with routing peformance on older consumer home equipment / routers.

Even many small/medium business grade routers weren't able to to handle the routing necessary for speeds upward of 30+ Mbps until recently (last few years).

They could handle LAN based switching fine but routing performance was weak as many have found out.

[John Cuccia]

My best test results are with the Comcast server in Houston.

[John Cuccia]

I use this site for intranet speed testing:

http://speed.lusfiber.net:81/

>> read more �

[Bryan Fuselier]

This server tests the Intranet

http://speed.lusfiber.net:81

This server tests the Internet

http://speedtest.lusfiber.net

read more »

[Bryan Fuselier]

look at modifications below

This server tests the Intranet

http://speed.lusfiber.net:81

This server sits in a substation on the intranet. Before your traffic gets shaped to go out to the Internet.

 

 

This server tests the Internet

http://speedtest.lusfiber.net

This server sits in the headend AFTER your traffic gets shaped. You aren't _really_ testing your internet connection. Just testing your internet speed before you leave the network.

[John St. Julien]

Thanks Bryan; this and your previous post really help.

All: 

I am trying to assimilate/summarize the whole of this thread for my own understanding; where I'm wrong please correct:

1) On the original question of a possible slowdown at night: We didn't generate any evidence that such existed but didn't disprove it either. —It appears that for the limited time we've tried that folks who used the Hammond server and had the 50 meg package were seeing near or above their tier numbers. That at least shows that any problem was not consistent but it didn't go on long enough to prove that an intermittent problem doesn't exist.

FYI: I'm abandoning the use of the wave mechanism in Ookla's speedtest for this purpose. It's really not suited for collective use to determine path or time issues as you can't isolate either time or path effectively from Ookla's wave page...as it stands now we've got multiple times, multiple servers and even a test from AT&T--none of which data can be disentangled. Useless. Oh well....I'd be interested in any suggestions that would allow for a group to do this kind of work together. 

2) On Bryan's suggestion that it might be an edge problem that came up rather early: it now appears that LUS feels that its load balancing between AT&T and Qwest at the edge of our network could be improved so Bryan's idea seems to have face validity. Hooray...

3) In the course of fiddling around it has been looking like there is a pretty consistent pattern of getting less upload than download speed when hitting the larger internet. I'm still trying to figure things out here. As I understand it the backbone and middle mile connections are symmetrical as they'd pretty much have to be logically—unlike endpoint connections they don't have a real "up" or "down." 

If we consider the servers that we are hitting when we test to be endpoints then it _could_ be that their connection is not symmetrical but since their upload would be our download asymmetry set up by commercial providers usually favors the download...so if that were the case we'd see better _uploads_ than downloads. (I have seen this on a number of my tests in the past and this is a potential explanation.)

On the other hand: Do people sometimes set up their servers balancing functions so that their upload---what they send to users--- is favored over their download--typically users' requests? If so that could be an explanation.

I'm puzzled.

What do you all think?

John

[Raymond Camden]

Second URL doesn't seem to work.

[Bryan Fuselier]

sorry... the second link should be http://speedtest.lusnet.net

[Bryan Fuselier]

Ookla uses 60 byte packets for their test. Most rate limiting devices "miss" rate shaping some packets when the flow is of small packets. Rate limiting devices need at lest 180 byte packets to rate shape ALL packets. LUS's test servers use 1500 byte SOCKET tests which is a true test as this would replicate FTP'ing..etc.. 

[Bryan Fuselier]

Looks like Ookla changed things up some. When we configured these servers, they were at 60 byte packets. I decided to double check my information after sending that and it appears they moved to 1434 byte packets... but they're still not doing SOCKET tests

This basically means we aren't comparing apples to apples with speedtest.net and speedtest.lusnet.net.

[Bryan Fuselier]

Here's some light reading that details what i'm talking about a little more

http://www.myconnectionserver.com/support/faq.html

[John Cuccia]

Thanks.

I'm interested in seeing what kind of intranet speeds people are seeing, and what kinds of routers they are using.  I typically get about 93 Mbps up and down, with an Intel Atom-based system running OpenBSD.

I've read that consumer-grade routers can't provide full intranet speeds, but I've never tried one.

[John Cuccia]

Ah, thanks again.

I guess that explains why I get almost exactly the 30Mbs that I pay for when using LUS' internet tester, and faster than that when testing at some outside servers?� The Ookla packets are slipping through the LUS traffic shaper.


On 3/16/2011 2:23 PM, Bryan Fuselier wrote:

Ookla uses 60 byte packets for their test. Most rate limiting devices "miss" rate shaping some packets when the flow is of small packets. Rate limiting devices need at lest 180 byte packets to rate shape ALL packets. LUS's test servers use 1500 byte SOCKET tests which is a true test as this would replicate FTP'ing..etc..�

On Wed, Mar 16, 2011 at 2:01 PM, John St. Julien <john...@gmail.com> wrote:

Thanks Bryan; this and your previous post really help.

All:�

I am trying to assimilate/summarize the whole of this thread for my own understanding; where I'm wrong please correct:

1) On the original question of a possible slowdown at night: We didn't generate any evidence that such existed but didn't disprove it either. �It appears that for the limited time we've tried that folks who used the Hammond server and had the 50 meg package were seeing near or above their tier numbers. That at least shows that any problem was not consistent but it didn't go on long enough to prove that an intermittent problem doesn't exist.

FYI: I'm abandoning the use of the wave mechanism in Ookla's speedtest for this purpose. It's really not suited for collective use to determine path or time issues as you can't isolate either time or path effectively from Ookla's wave page...as it stands now we've got multiple times, multiple servers and even a test from AT&T--none of which data can be disentangled. Useless. Oh well....I'd be interested in any suggestions that would allow for a group to do this kind of work together.�

2) On Bryan's suggestion that it might be an edge problem that came up rather early: it now appears that LUS feels that its load balancing between AT&T and Qwest at the edge of our network could be improved so Bryan's idea seems to have face validity. Hooray...

3) In the course of fiddling around it has been looking like there is a pretty consistent pattern of getting less upload than download speed when hitting the larger internet. I'm still trying to figure things out here. As I understand it the backbone and middle mile connections are symmetrical as they'd pretty much have to be logically�unlike endpoint connections they don't have a real "up" or "down."�

If we consider the servers that we are hitting when we test to be endpoints then it _could_ be that their connection is not symmetrical but since their upload would be our download asymmetry set up by commercial providers usually favors the download...so if that were the case we'd see better _uploads_ than downloads. (I have seen this on a number of my tests in the past and this is a potential explanation.)

On the other hand: Do people sometimes set up their servers balancing functions so that their upload---what they send to users--- is favored over their download--typically users' requests? If so that could be an explanation.

I'm puzzled.

What do you all think?

John

On Mar 16, 2011, at 10:44 AM, Bryan Fuselier wrote:

LUS does not contract the speed test. They built the speedtest server themselves using a third party software. I helped them install it. The server is sitting at a substation on the local intranet.

The results are different due to internet congestion. Once you test against anything outside of the LUS intranet, you are bound to the limitations of the connections from that point out. When testing on http://speedtest.lusnet.net you will get true results for intranet speeds. Once it hits Qwest/AT&T, you're at the mercy of a large portion of internet users in the tri-state area. Chances are, the much slower upload speeds are a result of the test point not being able to handle 50 Mbps back to you. Keep in mind, until the last year or so, 99.99% of people hitting these test servers were testing 15/1.5 type connections. MOST of these test servers are probably on 1 Gbps connections. 10 LUS subscribers with 100 Mbps would bring it to it's knees if they all tested simultaneously. Considering the millions of people online at night, it's a good possibility the connections surrounding these test servers are hit pretty hard on a regular basis.

Run the LUS speedtest again. After it's done, click the Graph tab on the left side of the chart. Click "Click here for detailed analysis". On the resulting page, after the second graphic, there will be an option to download your results in text format.

On Wed, Mar 16, 2011 at 10:25 AM, Robert <rosbo...@gmail.com> wrote:

Thanks Bryan. I'll test again tonight. I wonder if it's possible to
run a capture/tracer of the site that LUS Fiber provides for testing
Internet speeds. Where is this one routed, and why does this LUS site
indicate much faster upload speeds than Speedtest.net?

http://speedtest.lusnet.net/

I wonder who LUS has contracted with for speed testing, and how it's
routed there? This LUS speedtest site not only consistently indicates
higher download speeds, but much higher upload speeds, which would

support the expected symmetrical service up and down. �But...the

upload speeds are consistently much lower on all other Internet speed
testing sites- the most reputable probably being Speedtest.net. I'm
curious about this. The trend thus-far on the limited 'wave' results
is showing non-symmetrical and much slower upload speeds. Someone on
AT&T posted very nice speeds (particularly upload) to our wave.

I'm happy- just curious :)

Robert

On Mar 16, 8:49�am, Bryan Fuselier <digerati.sen...@gmail.com> wrote:
> As a wholesaler, we get maintenance notifications from the LUS NOC. Last
> night they performed a maintenance with the reason:
>
> *Purpose:***
>

> *Reset Core network equipment to induce load balancing �***

>
> *Summary:***
>
> *To ensure network traffic across both LUS Fiber Internet vendors is load
> balanced to increase efficiency and reduce congestion*
>
> This happened last night at midnight. Things should be better now.
>

> On Tue, Mar 15, 2011 at 11:21 AM, Dane DeValcourt <dane.devalco...@gmail.com

>
>
>
>
>
>
>
> > wrote:
> > Well there ya have it. Even from LUS it's going to Dallas via Qwest then to
> > the HB.
>
> > I don't recommend using the HB server, I'd just use Dallas if it was me.
>

> > On Mar 15, 2011, at 10:13 AM, Bryan Fuselier <digerati.sen...@gmail.com>

> > wrote:
>
> > here you go...right after it leaves my router then �it basically times out

> > after this. but the last ip is owned by Hunt
>

> > 3 �76-72-16-2.PHK.stat.lusfiber.net (76.72.16.2) �7.329 ms �6.913 ms
> > �7.470 ms
> > �4 �* * *

> > �5 � <http://iah-edge-05.inet.qwest.net>iah-edge-05.inet.qwest.net

> > (67.135.15.245) �10.964 ms �11.083 ms �11.207 ms

> > �6 � <http://dap-brdr-03.inet.qwest.net>dap-brdr-03.inet.qwest.net(67.14.2.89) �60.832 ms �12.097 ms �12.720 ms

> > �7 �63.146.27.126 (63.146.27.126) �16.864 ms �16.989 ms �16.681 ms
> > �8 �0.ae1.XL4.DFW7.ALTER.NET (152.63.96.86) �17.488 ms �17.348 ms �17.085
> > ms
> > �9 �POS7-0.GW1.DFW13.ALTER.NET (152.63.103.89) �19.694 ms �19.675 ms
> > �19.673 ms

> > 10 � <http://hbcorporate-gw.customer.alter.net>

> > hbcorporate-gw.customer.alter.net (63.65.120.250) �19.977 ms �20.505 ms
> > �19.797 ms
> > 11 �72.20.191.129 (72.20.191.129) �62.352 ms �62.593 ms �57.607 ms
>

> > On Mon, Mar 14, 2011 at 7:03 PM, Dane DeValcourt <<dane.devalco...@gmail.com>

> > dane.devalco...@gmail.com> wrote:
>

> >> Well I just did a capture to determine more info on the Hammond server.
>
> >> I captured 207.29.218.115
>
> >> According to ARIN whois this belongs to Hunt Brothers and corresponds to
> >> what Speedtest.net says is the sponsor:
>
> >> <http://whois.arin.net/rest/net/NET-207-29-208-0-1/pft>

> >>http://whois.arin.net/rest/net/NET-<207-29-208-0-1>207-29-208-0-1/pft

>
> >> Here is their network map from their website:
>

> >> <http://www.hunttelecom.com/images/networkmap-17january2008revision2-c...>
> >>http://www.hunttelecom.com/images/networkmap-17january2008revision2-c...

>
> >> My tracert (I'm on Cox however) shows me hitting Dallas and hoping on to

> >> <http://tinet.net>tinet.net which continues over to them.

>
> >> � 5 - I leave Cox at this hop
> >> � 6 � �94 ms � �88 ms � 123 ms �xe-3-0-0.dal33.ip4.tinet.net[89.149.183.53]

> >> � 7 � �91 ms � �88 ms � �91 ms �<http://hunt-brothers-of-louisiana.ip4.tinet.net>

> >> hunt-brothers-of-louisiana.ip4.tinet.net [77.67.71.226]
> >> � 8 � 108 ms � 110 ms � 106 ms �72.20.191.129

> >> � 9 � 107 ms � 107 ms � 107 ms � <http://www3.huntbrothers.com>

> >> www3.huntbrothers.com [207.29.218.115]
>
> >> Their AS is 32592
>
> >> Their peering info is:
>
> >> <http://www.robtex.com/as/as32592.html#peer>
> >>http://www.robtex.com/as/as32592.html#peer
>

> >> Now on the LUS side I see that <http://speed.lusfiber.net>

> >> speed.lusfiber.net resolves to 74.80.40.9
>
> >> This is an LUS address: �<http://whois.arin.net/rest/net/NET-74-80-0-0-1/pft>

> >>http://whois.arin.net/rest/net/NET-74-80-0-0-1/pft
>
> >> LUS AS is 25921
>
> >> Their peers are:
>
> >> <http://www.robtex.com/as/as25921.html#graph>
> >>http://www.robtex.com/as/as25921.html#graph
>
> >> Basically AT&T and QWest it would seem.
>
> >> I'd be interested in someone on LUS fiber doing a tracert to the Hammond

> >> server (207.29.218.115) and sharing the results. �I'm very curious as to the

> >> path since according to the Hunt Brothers map there is a DS3 link shown
> >> between Lafayette and Hammond but it doesn't detail anything as to what DS3
> >> that is with.
>
> >> Hope thats helpful or interesting at least.
>
> >> Regards,
> >> Dane
>

> >> On Mon, Mar 14, 2011 at 3:45 PM, Robert < <rosborne...@gmail.com>
> >> rosborne...@gmail.com> wrote:
>
> >>> John, thanks for your help. Dane, your comments probably explain why
> >>> when I'm on the Speedtest.net site, if I let the Speedtest program
> >>> determine my "best" server (based on ping time), it will choose either

> >>> Dallas- or interestingly enough- last night it was Temple, TX. �I had

> >>> IMHO. �You will often find that the actual path to things locally will first

> >>> go out to Dallas or some other peering point before making it's way back to
> >>> say a server in Hammond.
>
> >>> > If the test doesn't reveal the IP of the testing server then I'd sniff

> >>> a test to a few different servers and capture some IPs. �Then traceroute to

> >>> them and confirm the actual path and hops taken.
>
> >>> > Depending on who LUS is peering with will impact your route / path to
> >>> various sites.
>
> >>> > On Cox the Dallas server tends to give best results since that's a
> >>> major peering point, most traffic to the net from Cox will go through Dallas

> >>> regardless. �Obviously the New Orleans test yields good results on Cox but

> >>> it's a Cox server so I don't think it's a fair or accurate test for others.
>
> >>> > A LUS customer trying to test with say the Cox New Orleans server is

> >>> likely going to go through Dallas then to New Orleans. �So in that case it

> ...
>
> read more �

--

You received this message because you are subscribed to the Google Groups "Lafayette Technology" group.
To post to this group, send email to lafaye...@googlegroups.com.
To unsubscribe from this group, send email to lafayettetec...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lafayettetech?hl=en.

--

You received this message because you are subscribed to the Google Groups "Lafayette Technology" group.
To post to this group, send email to lafaye...@googlegroups.com.
To unsubscribe from this group, send email to lafayettetec...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lafayettetech?hl=en.

The best way to predict the future is to invent it. --Alan Kay

blog.lafayetteprofiber.com/

Supporting Fiber To The Home in Lafayette, Louisiana

--

You received this message because you are subscribed to the Google Groups "Lafayette Technology" group.
To post to this group, send email to lafaye...@googlegroups.com.
To unsubscribe from this group, send email to lafayettetec...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lafayettetech?hl=en.

[Robert Osborne]

I use the latest model Airport Extreme Gigabit Router with direct Cat 5e and Cat 6 ethernet cabling plus Wireless N 5gHz for laptop connectivity. I'm using a high-end Mac dual core computer but not one of the latest quad core models. If I'm connected by ethernet, the LUS 'Intranet' test site will give me 94Mbps download and around 90Mbps upload- nice- on most days/nights anyway. This is with either a direct connection to the main ethernet cable, or after connecting through the Apple Extreme (Gigabit) router- no difference. That means my router is good. If I use the Wireless N at my typically close ranges, the LUS 'intranet' test site gives me a max of about 80Mbps download and upload. The exception to these great numbers was when I made my original post- during peak hours, several nights in a row. That was when I was getting really poor numbers (at night) testing from both the LUS 'internet' and 'intranet' testing sites. This seems to have resolved now, as I'm not seeing the slowdowns at night anymore :)  Something changed for the better when LUS tech support began investigating  and testing the problem. It's pretty clear to me based on the above info that I don't have a hardware (computer/router) or wiring (fiber/ethernet) issues. I've tested with multiple browsers, and the results are similar. My antivirus/firewall software, browser add-ons, etc, were disabled for testing, and interestingly, performance was equally good even with this extra software running- no difference in speed testing.

Bryan, I think you have clarified things for me. Once these the data packets leave our fiber ring, we are limited by greater Internet congestion during peak hours, along with overloaded servers outside of our LUS fiber network. Congestion on our fiber ring is probably not a limiting factor right now, because of the quality and bandwidth available to us locally :)

Robert