<?xml version="1.0" encoding="UTF-8"?>

<rss version="2.0" xmlns:blogChannel="http://backend.userland.com/blogChannelModule">

<channel>
<title>Re: Packet Loss/Latency Reports in Speakeasy</title>
<link>http://www.dslreports.com/forum/r8085406</link>
<description></description>
<language>en</language>
<pubDate>Tue, 01 Dec 2009 04:53:34 EDT</pubDate>
<lastBuildDate>Tue, 01 Dec 2009 04:53:34 EDT</lastBuildDate>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8114304</link>
<description><![CDATA[<A HREF="/useremail/u/585933"><b>sh0V3L</b></A> : Ok  now 5 mins later  it clears up so i stress test a lil by pinging epic with  1472 byte packets :<br><br>Microsoft Windows 2000 [Version 5.00.2195]<br>(C) Copyright 1985-2000 Microsoft Corp.<br><br>C:\>ping www.epicgames.com -t -l 1472<br><br>Pinging www.epicgames.com [207.135.145.4] with 1472 bytes of data:<br><br>Reply from 207.135.145.4: bytes=1472 time=80ms TTL=117<br><br>Reply from 207.135.145.4: bytes=1472 time=70ms TTL=117<br><br>Ping statistics for 207.135.145.4:<br>    Packets: Sent = 199, Received = 199, Lost = 0 (0% loss),<br>Approximate round trip times in milli-seconds:<br>    Minimum = 70ms, Maximum =  90ms, Average =  71ms<br>Control-C <br><br>This Instability should not be a charicteristic of an sdsl circuit  and they need to address this issue as it has not gone away by itself  ive been backhauled  depro repro  diff  ips nothing changes the internitant instabilty  and of course it wont do it when im on the phone with them and pipj can kiss my ass  my personal account mngr  wtf it was so much better  service /tech support before they started the personal account mngr BS. IMHO speakeasy has changed they have become the attbi/comcast of the dsl market  i feel for kat being  stuck in this  she used to be able to get things done for ppl but now it appears she just cant do the things as before , must be the new ceo  of course this just my opinion <br><br>the above jpeg shows they can do sdsl right but why cant they do stability also ? i have had an open ticket for over a month i refuse to close it until this is stable  and will continue to request credit  for services not recieved <div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/8114304?c=439866&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="147189 bytes" WIDTH=600 HEIGHT=450 SRC="/r0/download/439866.thumb600~e9420e5b531d3b6cec81c6a4887bca3b/sdsl2.jpg/thumb.jpg" ALT="Click for full size"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8114304</guid>
<pubDate>Wed, 01 Oct 2003 13:10:44 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8114237</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> : Lol...they closed my trouble ticket saying it was resolved.  I get the same PL and I also have serious circuit issue thats brought my speedtest down to 352/33.  Yet, my ticket shows "resolved"...<br><br>Self]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8114237</guid>
<pubDate>Wed, 01 Oct 2003 13:00:51 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8114023</link>
<description><![CDATA[<A HREF="/useremail/u/585933"><b>sh0V3L</b></A> : i dont know what to say i geuss a picture is worth a 1000 words  <br><br>the battle for a decent connection continues of course they say my connections fine @##%&$!!!!!!!!<br><i>[text was edited by author 2003-10-01 12:41:53]</i><br><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/8114023?c=439854&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="172078 bytes" WIDTH=600 HEIGHT=450 SRC="/r0/download/439854.thumb600~f65548c4923605c2e2f184f9da3ee2c4/sdsllol..jpg/thumb.jpg" ALT="Click for full size"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8114023</guid>
<pubDate>Wed, 01 Oct 2003 12:28:52 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8091625</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> :  <BLOCKQUOTE><SMALL>said by  macmouse <A HREF="/useremail/u/637997"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>For whatever its worth on speakeasy's site (system status) it looks like they now officially saying there is an problem. (Or at least, its on their page instead of just in this forum.) Its for SEA,NYC and CHI. Message identical except for city names. Adjust as necessary ;)<br><br><HR><br>               09/26/03 02:18:07 PM&nbsp;&nbsp;Seattle POP Packet Loss<br><br>             Region&nbsp;:&nbsp;Seattle<br>        E.T.A.&nbsp;:&nbsp;(none)<br>        Services&nbsp;Affected&nbsp;:&nbsp;Some broadband services<br>      <br><br>             We are presently seeing packet loss on one of our Seattle POP&#146;s backhaul circuits caused by an unexpected increase in traffic caused by Internet worms.  We will be fully upgrading this POP within the next few months and are presently investigating interim solutions to these packet loss issues.        <HR></BLOCKQUOTE><br><br>I'm going on 6 weeks and counting with a worthless connection(gaming). I wonder how long it's going to take to "investigate" and find an interim fix before the POP upgrade.  sigh...:(]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8091625</guid>
<pubDate>Sun, 28 Sep 2003 21:27:09 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8091435</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Switched back over to the ADSL line at 08:45 this morning.  By 13:00 it was unusable due to the infamous "socket stalling" problem.  It's now 18:01 and the problem is quite apparent.<br><br>Back to the cable modem.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8091435</guid>
<pubDate>Sun, 28 Sep 2003 21:02:22 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8085406</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Interesting post, scooby.  I've taken up the details with you in private, but the Juniper in question was an M40 (I provided pictures so you can see that I'm not talking out my rear ;-) ).<br><br>It's likely that the unit was misconfigured, and it's highly likely that they're _still_ misconfigured.  I no longer work there (thanks for laying off 85% of your work force, Verio!), but I still occasionally see "Verio networking madness," especially since InterNAP has a peering link with Verio.<br><br>Thanks for clearing up the software vs. hardware issue as well.  The individuals who told me they were software-based was one of the Verio network administrators I knew, which may explain how and why the units were misconfigured.<br><br>Either way, thanks for stepping in and saying something.  *thumbs up*<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8085406</guid>
<pubDate>Sun, 28 Sep 2003 01:26:41 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8085181</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : sorry folks, looks like its wait till it gets done<br><i>[text was edited by author 2003-09-28 00:55:53]</i><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8085181</guid>
<pubDate>Sun, 28 Sep 2003 00:51:12 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8084689</link>
<description><![CDATA[<A HREF="/useremail/u/637997"><b>macmouse</b></A> : For whatever its worth on speakeasy's site (system status) it looks like they now officially saying there is an problem. (Or at least, its on their page instead of just in this forum.) Its for SEA,NYC and CHI. Message identical except for city names. Adjust as necessary ;)<br><br><HR><br>               09/26/03 02:18:07 PM&nbsp;&nbsp;Seattle POP Packet Loss<br><br>             Region&nbsp;:&nbsp;Seattle<br>        E.T.A.&nbsp;:&nbsp;(none)<br>        Services&nbsp;Affected&nbsp;:&nbsp;Some broadband services<br>      <br><br>             We are presently seeing packet loss on one of our Seattle POP&#146;s backhaul circuits caused by an unexpected increase in traffic caused by Internet worms.  We will be fully upgrading this POP within the next few months and are presently investigating interim solutions to these packet loss issues.       ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8084689</guid>
<pubDate>Sat, 27 Sep 2003 23:46:16 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8084672</link>
<description><![CDATA[<A HREF="/useremail/u/380736"><b>scooby</b></A> :  <BLOCKQUOTE><SMALL>said by  koitsu <A HREF="/useremail/u/659143"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>IMPORTANT: <B><I>The problem at hand with SE might not have ANYTHING to do with Juniper equipment!</I></B>  It might be something else; I have no idea.  But when Kat says the equipment is oversaturated in regards to how many pps (packets per second) the equipment can push out, the first thing I think of is their Junipers.  Software routing, ugh.<br> <HR></BLOCKQUOTE><br><br>Either you were using a beta product or one of their 'lollypops'.  Juniper used to let you have the OS to install on a pc to play with so you could teach people how they work without using a router that was in production.<br><br>Junipers are complete hardware routers.  Whoever told you they were software routers was incorrect.  There is no way you could push the following amount of data through a software router.<br><br>M5 - 3.2-Gbps full duplex (6.4 Gbps total)<br>M10 - 6.4-Gbps full duplex (12.8 Gbps total)<br>M20 - 12.8-Gbps full duplex (25.6 Gbps total)<br>M40 - 25.6-Gbps full duplex (51.2 Gbps total)<br><br>and the processor in each can handle 40 million packets per second.<br><br>Oh and btw, a very common router used at ISPs the Cisco 7513 spec'd to the max only handles .5 million packets per second.<br><i>[text was edited by author 2003-09-27 23:47:56]</i><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8084672</guid>
<pubDate>Sat, 27 Sep 2003 23:44:22 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8084374</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Dave,<br><br>Your problem definitely sounds unrelated to this thread.  This thread is discussing problems with Speakeasy IP network reliability and not DSL-related issues.  Your issue definitely sounds DSL-related, especially if you were losing sync.  I'd ask for noise margins to be provided (you can ask for this on the Covad forum if you have your Covad Circuit ID #), as well as ask Speakeasy to have Covad run an MLT test (which will report back the physical electrical distance between you and your Central Office (Verizon)).<br><br>Hope this helps, but please remember this thread is for IP networking issues (packet loss, primarily).  :-)<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8084374</guid>
<pubDate>Sat, 27 Sep 2003 23:12:46 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8083520</link>
<description><![CDATA[<A HREF="/useremail/u/880321"><b>davec22</b></A> : Hi:<br><br>I have been a customer of Speakeasy&#146;s since January 2000.  My legacy SDSL 384/128 service typically runs in the 300&#146;s in both directions.  I am connected to the Boston POP, and my setup is a SpeedStream 5250 bridge attached to a Linksys WAP Router configured with a static IP.  I have 3 PC&#146;s networked, 2 Win98 SE&#146;s using Cat 5 cable and 1 XP Pro laptop using WiFi.  For the first 3 &frac12; years, I was as happy as any SE customer could be&#133;maybe a few hours of downtime in several years, just a handful of trouble tix, and plenty of help from tech support when needed.  I touted my Speakeasy DSL service as awesome to anyone who would listen.  <br><br>In early August 2003, I started to experience intermittent outages.  First, my connection was more up than down, then it was more down then up.  The bridge lights would go from 4 green to the retraining cycles, typically not successfully retraining.  I opened a trouble ticket, a few days later the problem disappeared, so I closed the ticket.<br><br>A few days after that, the problem reappeared (intermittently more down than up), so I opened a second trouble ticket and began working with advance tech Jesse x248.  We went through the litany of tests&#133;swapping out cables, doing the on the phone testing with Covad, etc.  We had Verizon come out and check the box on the side of my house as well as the connection at the pole 600 ft. off of the house.  All was deemed fine, and Jesse fed me the &#147;it&#146;s either your inside wiring or your bridge is failing&#148; line.  I believed him and was either going to a) upgrade to ADSL with a Covad Pro Install to get new equipment, a NID filter, and my wires checked, b) buy a new bridge and stick with the service I have, or c) (heaven forbid) switch to Verizon DSL or Comcast.<br><br>Before I could decide which way to go (leaning towards a), of course), the problem disappeared.  I closed the ticket and life was grand again thru much of September.  Then, late this week (Th 9/25), the problems began again, this time with a new symptom.  Not only did the bridge keep retraining unsuccessfully, but for most of Thursday and part of Friday, the 4 lights were green, but I seemingly had no connection at all.<br><br>I stumbled upon this thread on Friday, and after reading it, it seems that my problems aren&#146;t really my own.  If I read this stuff correctly, all of you seem to be having similar ones.  Is it the hurricane, the blackout, the worms, or what?  I believed Jesse until I saw that the same &#147;it&#146;s your problem&#148; line has been fed to others.<br><br>Of course, by Friday night and all of today (Sat), my connection is up and humming as it should be.  So, my questions are:<br><br>1)	Do I have the same problem as all of you, or am I really missing the boat here and I have a different problem?  Could it truly be my wiring or my bridge?<br>2)	Can someone point me to a FAQ re: ping plotter, etc.?  I run the bos.speakeasy.net speed test, but haven&#146;t tested any of the other stuff you guys are throwing around on this thread.  What else should I be looking at, if anything?<br>3)	Should I upgrade or switch ISP&#146;s?  Based on what I read in this forum and the VOL forum, the intermittent problems are not going to disappear if I upgrade or switch.  You guys all refer to packet loss, ping times, etc&#133;is that the same thing as my intermittent problems?<br>4)	I am a little leery of upgrading to ADSL and the relating &#147;line sharing&#148;.  I like the fact that my SDSL is on a separate pair of copper wires than my dial tone.  Other than giving me more download speed for the same $$, what&#146;s the benefit to me of upgrading?  My 384 is fast enough for what I do (no gaming, little to no FTP, etc. &#150; just surfing, streaming music and emailing mostly) when it is humming.<br>5)	How else can I make this problem go away so that I can go back to being the happily satisfied, always connected SE customer that I once was?<br><br>Any thoughts or input any of you (including Kat!!) can provide would be much appreciated.<br><br>Thanks,<br><br>Dave C.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8083520</guid>
<pubDate>Sat, 27 Sep 2003 21:28:03 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8083442</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Junipers are essentially FreeBSD-based routers, to put it lightly.  Their interface cards do some CPU offloading (duh), but not as much as the Cisco cards do.  For example, at the time of my experiences with Junipers (2001 or so), their top-of-the-line advertised "backbone router" (model number I forget, sorry) was running off a Pentium II 450MHz CPU.  This was what they felt was suiting for a backbone router -- and not a border router, mind you.<br><br>Story time!<br><br>We experienced "Juniper stupidity" the instant a host on our network (just for documentation purposes, an EFnet-based IRC hub) got DDoS'd (the uplink was an OC48, the pps count was essentially that of an OC3).  That top-of-the-line Juniper turned into hunk of junk in a matter of seconds -- dropping packets, and doing weird things like packet forwards not getting executed (?!) and things of that nature.  It affected the ENTIRE facility -- which sported over 70 racks of co-location customers as well as technical support and sales departments.  Our Cisco would get slow and start to chunk a little bit, but it wouldn't die/malfunction.<br><br>Some of us SAs started poking fun at the Juniper with some tools we had, just to see what could effectively kill it.  We found that a simple 10mbit half-duplex Ethernet connection, running smurf (an extremely ancient DoS method), could literally bring that Juniper to a stand-still.  Yes, you read that right; 8-9mbit/s of broadcast traffic could totally bring down Juniper's top-of-the-line badboy.<br><br>We discussed this our immediate networking department (since Verio's NOC refused to discuss any networking details with us for reasons unknown to my manager as well as my manager's manager), who basically said "the Ciscos held up because they do hardware-level routing.  Most of the packet switching and filters are done via dedicated ICs; the Junipers offload most of this onto the CPU.  They can't handle heavy loads as well."<br><br>The advantages to the Juniper were that the interface for administrators was a lot more streamlined (the command-line interface is essentially UNIX), and navigation is easier.  Things are lot more dynamic (which I realise sounds pretty "buzzword-ish" coming from me, but it's hard to explain); sure, IOS is that way as well, but IOS relies extensively on the applicable hardware working how it should (i.e. any sort-of fault and IOS says "GAH!" and reloads the entire config).  The Junipers permitted the NOC folk to deploy filters and access lists a lot more quickly and reliably, plus be able to get more detailed information from the unit as to what was going on during packet storms and things of that nature.<br><br>Each company has their reasons for going to Juniper.  I think the three big ones are the following<br><br>1) Lower cost of ownership / maintenance<br>2) Easier to maintain / administrate<br>3) Tired of dealing with Cisco hardware and/or IOS bugs<br><br>Most of the time, these are the reasons I see people moving to Junipers.  You'd have to point out all of this over in the Advanced Networking forum -- although, I think the guys there would probably jump all over me for some of my statements (I'm not a network administrator!  Go easy on me, guys!).<br><br>I have absolutely *NO* problem with SE using Juniper equipment (other than the fact that I hate Junipers ;-) ).  If they want to go down that path, all power to them.  However, when it comes to deploying something like that, I URGE them to do what's called <B>TESTING</B>.  Send out an Email to some customers in each region deployment is planned for, and ask them if they'd like to be guinea pigs for new routing equipment/new network topologies.  Don't deploy it and then be like "BUT IT'S GREAT!".  <B>TEST</B> things first.  Users who would become guinea pigs could provide feedback.<br><br>IMPORTANT: <B><I>The problem at hand with SE might not have ANYTHING to do with Juniper equipment!</I></B>  It might be something else; I have no idea.  But when Kat says the equipment is oversaturated in regards to how many pps (packets per second) the equipment can push out, the first thing I think of is their Junipers.  Software routing, ugh.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8083442</guid>
<pubDate>Sat, 27 Sep 2003 21:17:56 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8082975</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : :(<br><br>this issue/thread has been going on how long????<br><br>service rating keeps dropping...]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8082975</guid>
<pubDate>Sat, 27 Sep 2003 20:11:31 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8082052</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :   <br>Hi koitsu -<br><br>Is the motive to move to Juniper just cost?  Or does software controlled routing mean that Juniper boxes offer ISPs many more options for traffic management policies?<br><br>Flexibility is usually expensive to implement in hardware, but cheap and easy in software, especially if the software architecture is partitioned into appropriate abstractions. The knobs will be cool and will all function as advertised, as long as the performance demands don't exceed operating limits, BEYOND WHICH the exception detection, propagation and handling elements of the software's architecture had better be pretty robust, or else there will be a constant refrain of, "I've fallen down and I can't get up."  ;-)<br><br>Maybe the problem isn't just that Juniper equipment offers less head room because of what it does in software rather than in hardware.  Maybe the problem is also that SpeakEasy is experimenting with new capabilities in the Juniper system, or worse, sold premium bandwidth on the assumption that they could implement new policies in the new equipment, either without onerous side-effects, or that they could do adequate spin-control on whatever side-effects they anticipated...    Maybe SpeakEasy bought a lemon, and is now stuck convincing the world that there must be something wrong with us if we're not happy being served lemonade.  ;-)<br><br><br>Am I just blowing smoke here?  Does anyone know enough about the flavors of traffic management policy that Juniper equipment offers on paper, even if some of them don't work as advertised?<br><br>Cheers,<br><br>Carl F.<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8082052</guid>
<pubDate>Sat, 27 Sep 2003 17:52:02 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8081865</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Carl,<br><br>Keep one thing in mind: Juniper routers <B><I>are NOT hardware-based</I></B>.  FE or ATM cards are used in the boxes, sure, but the actual processing is NOT done via hardware (re: ASICs).  Junipers are pure software routers, running a BSD derivative.  Ciscos, on the other hand, do a lot of hardware-based routing, and IOS simply interfaces with the appropriate chip (while some other features are handled purely by software).<br><br>I'm not going to say if this is the cause for what's going on, but in my eyes, software routers are absolute garbage for the sole reason you see here.  Junipers are presently a strong contender in the router market that's presently dominated by Cisco, for one sole reason: price.  They're much more affordable, which is why so many ISPs and backbone providers are steering away from Cisco.<br><br>Sadly, cutting on costs will simply bite them in the ass later when their customers cancel due to performance impact of the newly-deployed equipment (oops, did I say that outloud?).  We went through this exact situation at Verio back in 2001 or so; the Junipers made router administration much easier, and the unit itself was a lot easier to use.  However, the performance... ugh ugh ugh...<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8081865</guid>
<pubDate>Sat, 27 Sep 2003 17:28:45 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8081860</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : Carl,<br><br>I was just razzin ya on the choice of words (re: segregation)<br><br>:)<br><br>"In this case by contrast, we'd be imposing a temporary segregation in order to get a behavior change, that is, installation of a firewall and antiviral software. That makes my proposal more like giving a child a time-out, until they're ready to behave in a responsible, well-socialized way. "<br><br><br>That sounds like a good plan. I think instead of just speakeasy-wide, this should be internet wide. Whoever is still blasting my home apache testing server with code red should be sent to their room for 6 months :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8081860</guid>
<pubDate>Sat, 27 Sep 2003 17:28:14 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8080906</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :   <br>Hi SSIO -<br><br>Thanks for your detailed, informative post.<br><br>I now have some understanding as to why SpeakEasy is in the 90+th percentile in terms of Blaster impact.<br><br>Perhaps someone with relevant expertise can chime in and model how the degradation comes to be so uniform, if there are no restraining traffic management policies in place.  (As Bateson said, if he walked into a room and saw a group of monkeys banging out Shakespeare on typewriters, he'd look inside the typewriters.  ;-) )<br><br>As to your statement that no switching products provide the information to do analyses of traffic for behavioral signatures:<br><br>While it would make no sense to build any specific heuristics into hardware, ASICs are these wonderfully parallelized processing engines, where you could capture and buffer attributes of the stream, packet by packet, as it flows through, without impeding the stream.  You just fan-out copies of the attributes into parallel pipeline stages that write to dual-port buffers, that yet other processes read out.<br><br>You then write the software that uses heuristics to scan the stream, in this case, looking for IPs exhibiting problematic behavior.  Once a worm was captured and reverse-engineered, heuristics could be very tailored.  Since I would guess that processing would need to make multiple passes over the data, the software itself could also be pipelined, to run across multiple machines in the kind of cheapo, multi Linux-on-Intel server farm that is used for ASIC development.<br><br>The hardware buffers would likely overflow doing a 24/7 data capture.  But intermittent sampling of an hour or so would seem feasible, and could be triggered during meltdown traffic conditions.  Even if the offline heuristic analysis took a little while, I'm guessing it would be faster, more sensitive and more reliable than whatever ISPs are doing now to identify infected machines.<br><br>I have to say that it would astonish me to think that nothing like this exists, and that a total newbie like me could invent something like this in a newsgroup, especially since various flavors of DOS attack have been a problem for years now.  If the ability to capture this flow-through data does not exist in the current generation of switching products, perhaps this is the beginning of a lucrative business plan... ;-)<br><br>Cheers,<br><br>Carl F.<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8080906</guid>
<pubDate>Sat, 27 Sep 2003 15:31:32 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8080807</link>
<description><![CDATA[<A HREF="/useremail/u/459309"><b>Bondman</b></A> : It looks like the Detroit NAP to Chicago has gone to ***** again.  I guess I spoke too soon in my message earlier in this topic.  I am getting packet loss and double ping times since this morning.....<br>:[ sad<br>Ping statistics for 64.81.159.2:<br>    Packets: Sent = 76, Received = 73, Lost = 3 (3% loss),<br>Approximate round trip times in milli-seconds:<br>    Minimum = 14ms, Maximum = 44ms, Average = 32ms<br>:( frown]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8080807</guid>
<pubDate>Sat, 27 Sep 2003 15:19:02 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8080609</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :    <br>Hi Grocers Pet -<br><br>:-)<br><br>I didn't mean that computers become asymptomatic by themselves, as though their immune system eventually overcomes an infection.<br><br>I did mean that after infected users do a virus clean-up and install a firewall, their computers will observably stop generating lots of recognizably bogus traffic--using particular protocols and ports--and thereby be observably asymptomatic.<br><br>Also, I think I'd like to narrow your statement about segregation just a little.  Segregation based upon arbitrary, uncorrelated, superstitious, etc. criteria have never solved anything, and almost always makes things worse.<br><br>In this case by contrast, we'd be imposing a temporary segregation in order to get a behavior change, that is, installation of a firewall and antiviral software.  That makes my proposal more like giving a child a time-out, until they're ready to behave in a responsible, well-socialized way.  <br><br>Perhaps 'segregation' was not the best choice of words, given the many injustices with which it's associated.<br><br>Cheers,<br><br>Carl F.<br><br><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8080609</guid>
<pubDate>Sat, 27 Sep 2003 14:49:49 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8080597</link>
<description><![CDATA[<A HREF="/useremail/u/588258"><b>borborpa</b></A> :  <BLOCKQUOTE><SMALL>said by Carl F:</SMALL><HR>1.  What's the relationship between "incidents" and "infected computers"?<br><HR></BLOCKQUOTE>The incidents are abuse E-Mails sent to rr.com for infected computers, after they receive a certain number of complaints about a specific IP address.  There are only 1400 people that use MyNetWatchman, so the 650+ reports to rr is a lot.<br> <BLOCKQUOTE><SMALL>quote:</SMALL><HR> 2.  Are you saying that SpeakEasy has more infected computers within its customer base, or that SpeakEasy IP addresses are more frequently targeted from infected computers outside of SpeakEasy's customer base?<HR></BLOCKQUOTE>No, SE is more frequently targeted by rr.com addresses.  See more below.<br> <BLOCKQUOTE><SMALL>quote:</SMALL><HR> 3.  Could you elaborate a little more how the worm chooses its target IP addresses, and why that makes SpeakEasy more vulnerable?<HR></BLOCKQUOTE><br>The full explaination is at &raquo;<A HREF="http://www.f-secure.com/v-descs/msblast.shtml" >www.f-secure.com/v-descs/msblast.shtml</A> , but for basic terms, it takes your IP, and goes out from there.  SE IP's start with 66.92 and 66.93.  rr's major IP space sits at 66.91, so since SE is so close, it becomes an instant target.?<br> <BLOCKQUOTE><SMALL>quote:</SMALL><HR> 4.  What is the relationship of rr.com to SpeakEasy?  Why would rr.com's incidents take a toll on SpeakEasy, more than any other ISP?  (Also, what's the home URL for rr.com?)?<HR></BLOCKQUOTE>See above.  RoadRunner.com should be their main page.<br> <BLOCKQUOTE><SMALL>quote:</SMALL><HR> 5.  My understanding is that there are decent, basic firewall programs available for free.  What's the disincentive to SpeakEasy to do exactly what you're saying, that is, give folks a reasonable time to resolve the problem, under penalty of suspension of service?  I should think that losing income from a small percentage of customers would not begin to approach the costs of the equipment required to carry the extra load.  Not to mention the costs of all the calls to Tech Support, and the clear damage to their reputation.<HR></BLOCKQUOTE>Aside from bitchy customer's, there's no disincentive at all.  That's why I suggested it. :)<br> <BLOCKQUOTE><SMALL>quote:</SMALL><HR> 6.  Better yet, can SpeakEasy, as part of its "load-balancing", write a Perl-script or something that will dynamically segregate all symptomatic computers to their own router, until a computer becomes asymptomatic?  I think that would definitely qualify to match each customer's embodiment of "best effort", segregating the bad citizens to their own little community, where they can degrade each other's service, in isolation from the rest of us.  ;-)<HR></BLOCKQUOTE>That is actually a little too hard to try and do.  Since nothing exists to do that, they would have to put time, money, and effort into creating that...which would be a bit too much.<br> <BLOCKQUOTE><SMALL>quote:</SMALL><HR> 7.  Why, under random stress, does SpeakEasy's service degrade and then recover in such a well-structured way, if, as SpeakEasy claims, no traffic throttling or other traffic management policies are in force?  Apart from everything you've said, these data still need explanation from SpeakEasy.  To me, at least, the Blaster worm was the stressor that clearly exposed this well-structured behavior.  But whatever is imposing this structure on SpeakEasy's traffic flow is, I think, the root cause of the degraded service.  Traffic generators like worms amplify the damaging impact, but the root cause looks to me like some kind of traffic management policy that assures average bandwidth at the expense of increased variability.<HR></BLOCKQUOTE>Well, once you begin maxing out a connection, it does become very unstable, and variable.  Routers are "trained" to drop certain types of packet when they become overloaded.  I'm not the pro on this end of things, so my knowledge is limited to what I have seen and heard.<br><small>--<br>There are no stupid questions, but there are a LOT of inquisitive idiots.[AIM - BoyBandsMakeUGay]</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8080597</guid>
<pubDate>Sat, 27 Sep 2003 14:47:57 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8080340</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : 5. My understanding is that there are decent, basic firewall programs available for free. What's the disincentive to SpeakEasy to do exactly what you're saying, that is, give folks a reasonable time to resolve the problem, under penalty of suspension of service? I should think that losing income from a small percentage of customers would not begin to approach the costs of the equipment required to carry the extra load. Not to mention the costs of all the calls to Tech Support, and the clear damage to their reputation.<br><br>What's a reasonable amount of time? I suggest 3 days after notification. The reason is: The brain numbing amount of apathy I experience telling people that having a 24/7 always on net connection means a bit of responsibility. The response I hear often is: I am not into security, it wont happen to me. Until its too late. <br><br>Its not "if" its "when"<br><br>6. Better yet, can SpeakEasy, as part of its "load-balancing", write a Perl-script or something that will dynamically segregate all symptomatic computers to their own router, until a computer becomes asymptomatic? I think that would definitely qualify to match each customer's embodiment of "best effort", segregating the bad citizens to their own little community, where they can degrade each other's service, in isolation from the rest of us. <br><br>Computers just dont become 'asymptomatic' like getting over a cold.<br><br>Segregation, as we have seen through history has never really solved a thing.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8080340</guid>
<pubDate>Sat, 27 Sep 2003 14:12:04 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8079496</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :    <br>Hi SSIO -<br><br>For those of us who are relative newbies, your post needs a little unpacking.  :-)<br><br>1.  What's the relationship between "incidents" and "infected computers"?<br><br>2.  Are you saying that SpeakEasy has more infected computers within its customer base, or that SpeakEasy IP addresses are more frequently targeted from infected computers outside of SpeakEasy's customer base?<br><br>3.  Could you elaborate a little more how the worm chooses its target IP addresses, and why that makes SpeakEasy more vulnerable?<br><br>4.  What is the relationship of rr.com to SpeakEasy?  Why would rr.com's incidents take a toll on SpeakEasy, more than any other ISP?  (Also, what's the home URL for rr.com?)<br><br>5.  My understanding is that there are decent, basic firewall programs available for free.  What's the disincentive to SpeakEasy to do exactly what you're saying, that is, give folks a reasonable time to resolve the problem, under penalty of suspension of service?  I should think that losing income from a small percentage of customers would not begin to approach the costs of the equipment required to carry the extra load.  Not to mention the costs of all the calls to Tech Support, and the clear damage to their reputation.<br><br>6.  Better yet, can SpeakEasy, as part of its "load-balancing", write a Perl-script or something that will dynamically segregate all symptomatic computers to their own router, until a computer becomes asymptomatic?  I think that would definitely qualify to match each customer's embodiment of "best effort", segregating the bad citizens to their own little community, where they can degrade each other's service, in isolation from the rest of us.  ;-)<br><br>7.  Why, under random stress, does SpeakEasy's service degrade and then recover in such a well-structured way, if, as SpeakEasy claims, no traffic throttling or other traffic management policies are in force?  Apart from everything you've said, these data still need explanation from SpeakEasy.  To me, at least, the Blaster worm was the stressor that clearly exposed this well-structured behavior.  But whatever is imposing this structure on SpeakEasy's traffic flow is, I think, the root cause of the degraded service.  Traffic generators like worms amplify the damaging impact, but the root cause looks to me like some kind of traffic management policy that assures average bandwidth at the expense of increased variability.<br><br>Thanks ahead of time for your elaborations.<br><br>Cheers,<br><br>Carl F.<br><br><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8079496</guid>
<pubDate>Sat, 27 Sep 2003 11:57:35 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8078511</link>
<description><![CDATA[<A HREF="/useremail/u/588258"><b>borborpa</b></A> :  <BLOCKQUOTE><SMALL>said by Carl F:</SMALL><HR>I have no data that says that the SpeakEasy customer base had significantly more infections than average.  Personally, I think stories about bizarrely high infection rates are just red herrings, and that SpeakEasy was not infected at a significantly higher rate than other ISPs.<HR></BLOCKQUOTE>Actually, SE is still at the high end of it all, along with rr.com.  I use MyNetWatchmen to filter my Zone Alarm logs and send them to the proper ISP's.  I would say 75% of the reports go to RR.  Because of the way the worms choose their IP address, SE is at considerable risk from RR infected computers.  Accoring to &raquo;<A HREF="http://www.mynetwatchman.com/ListIncidentsByProvider.asp" >www.mynetwatchman.com/ListIncide&middot;&middot;&middot;ider.asp</A> , RR has 3.5 TIMES more incidents than any other ISP...so that definitely takes it's toll on SE.  I'm <I>still</I> seeing over 3000 hits per day, per IP (I have 8).  That's a LOT of extra overhead just tramping it's way around the internet all day pointlessly.<br><br>Of course, SE definitely needs to address the issue by sending out information to infected subscribers (which I'm sure they are doing).  They need to start getting a little strong-arm though, and if they see after 2-3 days the infected computer is STILL going at it, suspend service until that person corrects the problem.  RR <B>REALLY</B> needs to get on the ball, and get their systems fixed as well...<br><small>--<br>There are no stupid questions, but there are a LOT of inquisitive idiots.[AIM - BoyBandsMakeUGay]</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8078511</guid>
<pubDate>Sat, 27 Sep 2003 08:58:25 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8074098</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :     <br>Hi Whiteshp -<br>   <br>This does go round and round.  One after another engineer "connected" to SpeakEasy offering similar scenarios that do not make contact with critical data available on these threads.<br><br>SpeakEasy's own "propeller heads" need to be telling us the story, directly.  Leaking off the record to you is not nearly so helpful as would be talking on the record to all of us, the user base.<br><br>1.  I'm sorry to hear that business class SDSL is giving you grief as well. But that is a far cry from a definitive statement that there are NO premium classes of the kind I describe.<br><br>Mind you, I have no data that such a class exists.  It just occurred to me that such a premium class would be consistent with observation, and that someone with much more experience than I have might be able to tell me if such an animal exists, and what kind of customer/application it might be.  If no one makes any concrete suggestions over the next few days, I'll take it that this is just pointless speculation on my part.<br><br>2.  Interesting story about CPU time-slicing...  Are routers really implemented with general purpose processors in this way?  I would have thought this would have been done primarily in ASICs, to be able to keep up.  In either case, whether the algorithm is in software or silicon, it is not rocket science to build an arbiter that assigns priority on any of a number of criteria.<br><br>Again, I don't know nearly enough about network infrastructure equipment to know what traffic management policies are available to the ISPs who own and operate the equipment.  I'm asking questions to which I'm looking for answers.  Your time-slicing story doesn't fit, because I would expect much greater packet loss as opposed to just stalls, if queues were thrashing in the way you suggest.  If I think about it, it doesn't make sense to me.  :-)  But maybe I'm just another asshole with an opinion...<br><br>3.  The infection rate for Blaster was about 1%.  If the propeller heads you're connected to indicate that SpeakEasy's infection rate was much higher, then SpeakEasy owes us some explanation as to how the virus targeted SpeakEasy's customers with such greater precision than other ISP's customers, for example, a security breach of some broadly construed kind.<br><br>I have no data that says that the SpeakEasy customer base had significantly more infections than average.  Personally, I think stories about bizarrely high infection rates are just red herrings, and that SpeakEasy was not infected at a significantly higher rate than other ISPs.  At the same time, SpeakEasy does seem in the 90th percentile or higher in terms of impact incurred, and that does need explaining...but in terms of network architecture, not in terms of infection rates that imply a security or some other egregious issue.  On this one, I trust SpeakEasy, and reject conjectures about high infection rates at SpeakEasy.<br><br>4.  Again, here are the data that need explaining (round numbers, from memory, as my ability to get to these forums has been all wonky for the last few days).<br><br>6Sep03, Midday:<br>================<br>Download 350Kbps +/- 180Kbps, Upload 290Kbps +/- 1700Kbps (not a typo!!)<br><br>19Sep03, Midday:<br>================<br>Download 635Kbps +/- 26Kbps, Upload 640Kbps +/- 300Kbps<br><br>This behavior shows a remarkable amount of structure, especially for a system under stress.  Degraded performance is usually progressively more chaotic, less predictable performance.  Why not in this case, with SpeakEasy?<br><br>A. Why do download and upload bandwidths track each other so closely, both improving by about 1X?<br><br>B. How do upload and download bandwidths track each other so closely, when the upload variability is about 10X the download variability?  (This is really the most striking data point, given the randomness of traffic on the internet.)<br><br>C. Why do variabilities (the +/-) track each other so closely, both improving by about 6X?<br><br>D. Why is upload variability consistently so much greater than download variability?<br><br>To me these look, not like the random failures of a system under stress, but rather like traffic management policies that remained remarkably stable despite the high stress of the Blaster worm.  But what do I know, being fairly far away from my areas of expertise?<br><br>To be very clear here, I'm not saying I know the answers to any of these questions.  I'm not a networking engineer.  I do believe these are all good questions, and that SpeakEasy would do best to give us the answers to these questions, in the voice of their own propeller heads.  Those propeller heads built what was a great ISP until just very recently, so I am sure that they are a really competent bunch of folks with some substantial grip on what is really happening, whether or not they are allowed to say.<br><br>Cheers,<br><br>Carl F.<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8074098</guid>
<pubDate>Fri, 26 Sep 2003 18:05:31 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8073268</link>
<description><![CDATA[<A HREF="/useremail/u/595666"><b>whiteshp</b></A> : I've done a little digging.  I won't condone the actions of the techs to some of you.  Though I doubt they were given a choice as I'm sure someone in upper management thought delay would help the hemorrhage of customers. I don&#146;t think it is the best decision but it sounds like someone in upper management hopes for the general user not known is not there.  Thing is Speakeasy has many propeller heads who are well connected to each other.<br><br>If you log your pings like I do you can see that ICMP pings are flooding into all IP&#146;s.  With routers having to check packets for where to go millions of pings multiplied by thousands of infected computers is a nightmare for any router CPU.  Add in Microsoft Exchange servers must have ICMP and you can&#146;t just block it or you lose your business.<br><br>For those wondering if &#147;premium&#148; customers are protected while the others are left to the wolves.  I was told by tech that my SDSL priority would help shield me.  But my SDSL line is affected exactly and at the same as my ADSL line.  I can watch pings on both lines and watch them both grow at the same time and even hit packet loss.  But if you think it makes sense.  Packet priority only works when your CPU has enough time slices to check all the packets (decide which one should go first).  The CPU&#146;s in this case (routers connecting Speakeasy and some other ISP&#146;s) to Internap can&#146;t keep up.  So I can vouch as a SDSL customer with my business class routing my packets are getting missed too.<br><br>I have been told a (hoped) ETA that some new network equipment will be going into CHI at the end of this month to the early part of October.  This should help a lot as everyone goes through CHI one way or another.<br><br>To stay or go?  A lot of other providers are having problems with these worms as well.  This is not isolated to just Speakeasy so if I left I&#146;d need to be careful.  The other side of the coin is I LIKED my service quite well before all this garbage happened and I hate to lose it. I&#146;ve been with quite a few providers who really did SUCKK .  I can&#146;t speak for the rest of you but the ETA is fairly close.  It would take me longer to sign up for new DSL service.  So I&#146;ll wait and watch the date.  If it gets fixed good life goes on as expected.  If not I may be forced to check my alternatives.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8073268</guid>
<pubDate>Fri, 26 Sep 2003 16:27:09 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8072824</link>
<description><![CDATA[<A HREF="/useremail/u/312284"><b>bhan261</b></A> : No doubt many of us will start (or are already) doing this math.  And no doubt some of us will come to the same conclusion that even with the $300 cancellation fee, it will be cheaper AND you get a more reliable circuit by going elsewhere.  As I said a couple of months ago, the myth and the reality of Speakeasy being "worth more" are starting to diverge in the minds of many users.<br><br>And let me anticipate the response from certain SE fans....  <br><br>Yes, we know your circuit is fine but do you "get" that ours isn't?  <br><br>Yes, we know that RADSL is a "best efforts" service but do you "get" that there's good reason to suspect that "best efforts" aren't being given?<br><br>Yes, we like Kat and appreciate the work she does but it does not compensate for the fact that we're paying a premium price for what is a sub-premium service right now.  (Again, yes, we KNOW your circuit is perfect.)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8072824</guid>
<pubDate>Fri, 26 Sep 2003 15:27:35 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8072084</link>
<description><![CDATA[<A HREF="/useremail/u/173724"><b>LowJack</b></A> :  <BLOCKQUOTE><SMALL>said by  Yourself <A HREF="/useremail/u/183624"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR> <BLOCKQUOTE><SMALL>said by  borborpa <A HREF="/useremail/u/588258"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>Kat has said that Seattle has not yet been corrected, but will be in a week (or something).  I'm sure she will let everyone know as soon as it's fixed, so we can see results.<br> <HR></BLOCKQUOTE><br><br>The problem with that is that the tech support rep I spoke with 2 days ago said the interim fix had already been completed, which supposedly included my circuit.  Obviously that is not the case. <HR></BLOCKQUOTE><br><br>Exactly.  Tech support keeps lying to me.<br><br>I'm somewhat considering simply paying the $300 fee to cancel, and then going to cable, which is $20 a month for the next 6 months (a deal in my neighborhood) and then goes up to around $40 a month.<br><br>$300 + ($20*6) + ($40*6) = $660 /f year<br><br>or I could continue with speakeasy<br><br>$105 X 12 = $1,260 /f year]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8072084</guid>
<pubDate>Fri, 26 Sep 2003 13:52:57 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8070840</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :    <br>I have a question.<br><br>What kind of customer/application would fit the following profile?<br><br>1.  Traffic is generated outbound, that is, for upload, in large bursts, but with substantial intervals in between.<br><br>2.  The traffic is time sensitive, such that the customer would be willing to pay a premium to have the traffic delivered onto the network/internet as quickly as possible.<br><br>I'm asking this question because SpeakEasy seems to have made solid progress on both download bandwidth and download variability, but on the upload side, the progress has been adequate only on bandwidth.<br><br>One plausible reason is that they have a premium class of customer whose overall upload output allows SpeakEasy to maintain its promised upload bandwidth to all customers.  That is, the customers in this premium class do not need disproportionate bandwidth.  They just need to have other customers' traffic throttled when they are uploading, to assure high priority for their traffic, whenever they are uploading.<br><br>Customers like us, who are not in this premium upload class, would get the leftovers.  We'd get our advertised upload bandwidth, maybe even more.  However, whenever the premium customers were online, our upload variability would be unsuitable for many real-time interactive purposes, including those that SpeakEasy has advertised like Gaming.<br><br>Do such applications / customers exist?  If so, what flavor of animal or vegetable are they?<br><br>Cheers,<br><br>Carl F.<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8070840</guid>
<pubDate>Fri, 26 Sep 2003 11:10:18 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8069718</link>
<description><![CDATA[<A HREF="/useremail/u/312284"><b>bhan261</b></A> : In the past day or two, the horrible spikes in P/L in NYC have been accompanied by huge ping spikes.  In the words of Gilda Radnor, "if it's not one thing, it's another."]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8069718</guid>
<pubDate>Fri, 26 Sep 2003 07:29:20 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8069275</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Socket stalling problem has re-appeared tonight at about 23:30-23:45.  Line has been working "flawlessly" (i.e. no socket stalls) since my last post.  Ping Plotter shows happiness regardless (my ping packets are 56 byte, however).<br><br>I'm hoping this is being caused by some unmentioned maintenance somewhere, otherwise I'm going to get quite irate.<br><br>Back to the cable modem for the time being...<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8069275</guid>
<pubDate>Fri, 26 Sep 2003 03:14:18 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8067212</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> : I, for one, have no intention of being an apologist for SE.  My contract is up with one more payment and if this isn't resolved soon, I will move on to another ISP.  This is the 4th trouble ticket on my circuit in 10 months.  When I had a Verizon circuit through an independent ISP, I had a total of 4 service incidents in just under <B>4 years</B>.  So this is getting a bit tiresome....<br><br>Self]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8067212</guid>
<pubDate>Thu, 25 Sep 2003 21:58:18 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8066418</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :    <br>Hi SSIO -<br><br>Please don't slip into being an apologist for SpeakEasy.<br><br>From every report I've read lately, the mandate given<br>to Tech Support seems to be to avoid mentioning the<br>systemic problems, and to make each caller feel as though<br>they are the only one having the problem, or that the<br>problem is normal and not a problem or what-have-you.<br><br>I agree with what you said on another thread about<br>SpeakEasy having been great in the past.  But companies<br>change, especially when the board decides to bring in a<br>new CEO.<br><br>SpeakEasy is working on the Quality of Service problems,<br>but the Quality of Support has clearly degraded into<br>a circling of the wagons, rather than the honest and open<br>exchange that I felt I could always count on.<br><br>Please note that Kat is working hard on our Quality of <br>Service issues, but is remarkably silent on our Quality of <br>Support issues.  Wouldn't you expect Quality of Support<br>to be part of her charter, as Customer Experience Manager?<br>With Quality of Service, she seems to be managing the<br>SpeakEasy side, but with Quality of Support, she seems to<br>be putting more energy into managing *us* and how we<br>interpret and feel about SpeakEasy's support behavior.<br><br>Cheers,<br><br>Carl F.<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8066418</guid>
<pubDate>Thu, 25 Sep 2003 20:33:57 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8066158</link>
<description><![CDATA[<A HREF="/useremail/u/696918"><b>Endorphine</b></A> : I also have seen a huge degrade in service this last week on the Seattle POP. :(<br>I have been keeping ping plotter logs and my first hop used to be 12-13ms all day long.  As you can see from the picture below you get past 9am and it goes to around 30-34ms.<br>I understood also that they were going to being doing a major upgrade "this fall", but when is that going to be? <br>I am also in the Speakeasy Gaming Beta test, but that will be a joke if I keep getting so much packet loss/drops in most of the games I play.<br>I will try to be as patient as possible, but I hope Kat can give us an update soon.<br><br>Marc<div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/8066158?c=436098&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="29444 bytes" WIDTH=600 HEIGHT=423 SRC="/r0/download/436098.thumb600~7d789335cca3595b39b5bcd6218413ce/ping.symantec.com.png/thumb.jpg" ALT="Click for full size"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8066158</guid>
<pubDate>Thu, 25 Sep 2003 20:04:00 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8065040</link>
<description><![CDATA[<A HREF="/useremail/u/595666"><b>whiteshp</b></A> : Anyone seeing ping spikes on the Dayton NAP or is it just me?  I'm wondering if it's just me.  Things look near normal then they climb to 400+ for 10-15 seconds then drop back down.  I have asked tech support twice just curious and they act suprised and say there should be no problem here on our NAP.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8065040</guid>
<pubDate>Thu, 25 Sep 2003 17:54:31 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8064432</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> :  <BLOCKQUOTE><SMALL>said by  borborpa <A HREF="/useremail/u/588258"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>Kat has said that Seattle has not yet been corrected, but will be in a week (or something).  I'm sure she will let everyone know as soon as it's fixed, so we can see results.<br> <HR></BLOCKQUOTE><br><br>The problem with that is that the tech support rep I spoke with 2 days ago said the interim fix had already been completed, which supposedly included my circuit.  Obviously that is not the case.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8064432</guid>
<pubDate>Thu, 25 Sep 2003 16:35:04 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8064301</link>
<description><![CDATA[<A HREF="/useremail/u/588258"><b>borborpa</b></A> : Kat has said that Seattle has not yet been corrected, but will be in a week (or something).  I'm sure she will let everyone know as soon as it's fixed, so we can see results.<br><br>[EDIT] Here's what I was looking for...<br><BLOCKQUOTE><SMALL>Said by  KatOak <A HREF="/useremail/u/473126"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A></SMALL><BR><HR>We performed some upgrades to the SEA POP on Wednesday, but the full upgrade isn't scheduled for a couple more weeks, I believe. We are working on an interim solution for this and the NYC POP, however.<BR><HR></BLOCKQUOTE><br><SMALL>--<br>There are no stupid questions, but there are a LOT of inquisitive idiots.[AIM - BoyBandsMakeUGay]</SMALL><br><i>[text was edited by author 2003-09-25 19:45:52]</i><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8064301</guid>
<pubDate>Thu, 25 Sep 2003 16:20:12 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8064282</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> : Sigh...yep Seattle is still a mess.  Here is what I was seeing last night:<br><br>~45-60 ms to my first hop(usually 12-14)<br>20-50% Packet loss at my second hop<br>Speedtest results of 667/36 on a 1.5/384 line...<br><br>I use my line for gaming, so lately my service has been useless.  :(<br><br>Self]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8064282</guid>
<pubDate>Thu, 25 Sep 2003 16:18:17 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8063518</link>
<description><![CDATA[<A HREF="/useremail/u/173724"><b>LowJack</b></A> : I'm in the same boat.  Ever since a week or so ago, when they had the Seattle "maintenance" event, my line has been continually getting worse.<br><br>Usually my packet loss is 0% and my ping to the gateway is a solid 25ms.<br><br>[Tau-Ceti:~] cbishop% ping 216.254.16.1<br>PING 216.254.16.1 (216.254.16.1): 56 data bytes<br>64 bytes from 216.254.16.1: icmp_seq=0 ttl=63 time=41.149 ms<br>64 bytes from 216.254.16.1: icmp_seq=1 ttl=63 time=44.582 ms<br>64 bytes from 216.254.16.1: icmp_seq=2 ttl=63 time=31.596 ms<br>64 bytes from 216.254.16.1: icmp_seq=3 ttl=63 time=37.916 ms<br>64 bytes from 216.254.16.1: icmp_seq=4 ttl=63 time=38.922 ms<br>64 bytes from 216.254.16.1: icmp_seq=5 ttl=63 time=46.153 ms<br>64 bytes from 216.254.16.1: icmp_seq=6 ttl=63 time=45.293 ms<br>64 bytes from 216.254.16.1: icmp_seq=7 ttl=63 time=47.172 ms<br>64 bytes from 216.254.16.1: icmp_seq=8 ttl=63 time=44.933 ms<br>64 bytes from 216.254.16.1: icmp_seq=9 ttl=63 time=48.611 ms<br>64 bytes from 216.254.16.1: icmp_seq=10 ttl=63 time=41.876 ms<br>64 bytes from 216.254.16.1: icmp_seq=11 ttl=63 time=48.696 ms<br>64 bytes from 216.254.16.1: icmp_seq=12 ttl=63 time=48.73 ms<br>64 bytes from 216.254.16.1: icmp_seq=13 ttl=63 time=41.144 ms<br>64 bytes from 216.254.16.1: icmp_seq=14 ttl=63 time=42.072 ms<br>64 bytes from 216.254.16.1: icmp_seq=15 ttl=63 time=52.93 ms<br>64 bytes from 216.254.16.1: icmp_seq=16 ttl=63 time=32.681 ms<br>64 bytes from 216.254.16.1: icmp_seq=17 ttl=63 time=47.175 ms<br><br>It gets MUCH worse when I try to do anything.  My speed tests are normal this morning, but my upload dropped from the 768 region last night to the 128 region during the worst of it.<br><br>I call Speakeasy, nothing but pissed off techs telling me "we don't garauntee ping times call us when it's 100+".<br><br>You are a "gaming" ISP, asshats.  You better start garaunteeing them.<br><br>Some router log examples:<br><br>Sep/25/2003 10:26:35 	Drop ICMP packet from WAN	216.254.197.65:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 10:26:15 	Drop ICMP packet from WAN	216.254.223.158:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 10:25:47 	Drop ICMP packet from WAN	216.254.220.123:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 10:25:23 	Drop ICMP packet from WAN	216.255.194.31:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 10:25:00 	Drop ICMP packet from WAN	216.254.16.1:0	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 10:23:53 	Drop ICMP packet from WAN	216.254.214.137:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 10:23:47 	Drop ICMP packet from WAN	216.254.209.138:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 10:23:36 	Drop ICMP packet from WAN	216.254.3.30:8	216.254.16.31:0	Rule: Default deny<br><br>Another block:<br><br>ep/25/2003 10:01:40 	Drop TCP packet from WAN	65.33.248.200:2743	216.254.16.31:135	Rule: Default deny<br>Sep/25/2003 10:01:19 	Drop ICMP packet from WAN	216.254.220.158:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 10:01:01 	Drop ICMP packet from WAN	216.254.160.229:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 10:00:44 	Drop ICMP packet from WAN	216.254.162.64:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 10:00:18 	Drop ICMP packet from WAN	216.254.161.247:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 10:00:04 	Drop TCP packet from WAN	216.241.26.9:1606	216.254.16.31:135	Rule: Default deny<br>Sep/25/2003 10:00:01 	Drop TCP packet from WAN	216.241.26.9:1606	216.254.16.31:135	Rule: Default deny<br>Sep/25/2003 09:59:39 	Drop ICMP packet from WAN	216.254.234.23:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 09:59:38 	Drop ICMP packet from WAN	217.1.168.39:8	216.254.16.31:0	Rule: Default deny<br>Sep/25/2003 09:58:41 	Drop ICMP packet from WAN	216.254.209.4:8	216.254.16.31:0	Rule: Default deny<br><br>More ICMP requests today but yesterday there were nothing but port 135/137 requests from Speakeasy IPs.<br><br>MEH.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8063518</guid>
<pubDate>Thu, 25 Sep 2003 14:45:59 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8060862</link>
<description><![CDATA[<A HREF="/useremail/u/459309"><b>Bondman</b></A> : Hi Kate:<br>   Since the maintenance activity at the Chicago POP servicing the Detroit NAP things are very close to normal.  Thanks for working on this.  I held off responding to see if the fix would hold.  The only strange thing I ran into which I have covered in another topic is the inability to resolve webmail.registeredsite.com and pop.registeredsite.com with Speakeasy DNS servers.  From a Terminal Server session at a site that has a different ISP I can resolve these names to IP's.<br>  Thanks again for your help!]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8060862</guid>
<pubDate>Thu, 25 Sep 2003 08:00:24 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8058639</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : well as in regards to my area... only marginal packetloss/spikes, maybe 1 out of 500... the PDX/SEA POP Bridge is working fine for me at this point...<br><br>sorry to see you go catskinner...<br><small>--<br>I post for myself, from myself. Statements made do not necessarily reflect the views of my employer, Charter Communications, or any of its subsidiaries.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8058639</guid>
<pubDate>Wed, 24 Sep 2003 22:34:06 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8054721</link>
<description><![CDATA[<A HREF="/useremail/u/161504"><b>jesterekim</b></A> : Damn sorry to hear that. :(]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8054721</guid>
<pubDate>Wed, 24 Sep 2003 16:22:53 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8048364</link>
<description><![CDATA[<A HREF="/useremail/u/585933"><b>sh0V3L</b></A> : IM AM so fed up i just hung up om my acc manager and ive had it with speakeasy  at this point im looking for a way to get out without paying cancelation fees thats all i just want the f out  they changed my ip block hoping for better its now worse they wont go back they arent willing to do anything they see no problems  they think they can bs me well its not gonna fly its bye bye speakeasy ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8048364</guid>
<pubDate>Tue, 23 Sep 2003 21:56:32 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8047828</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Not too sure what's with the ICMP echos -- those are classic "ping" responses.  I'm almost 90% positive that a recent Win32 worm checks to see if a host is up this way, however.  I forget which worm.<br><br>TCP port 135 would be <A HREF="http://www.cert.org/incident_notes/IN-2003-03.html">W32/SoBig.F</A>.<br><br>TCP port 445 would be NetBIOS or SMB shares.<br><br>TCP port 1433 -- Microsoft SQL server.  Probably a trojan/virus of sorts looking to exploit MSSQL holes (and there are many).<br><br>TCP port 17300 -- Kuang2TheVirus.  No idea what this is, other than a virus.  ;-)<br><br>TCP port 80 (HTTP) is ""normal"" *cough cough*.  I get these as well.  They are almost always compromised or infected Windows machines running IIS, attempting to spread itself.  Most of the requests I get are "GET / HTTP/1.0" requests, sometimes they're simply "GET /default.ida?blahblahblah HTTP/1.0" for the (old but still active) IIS worm.<br><br>TCP port 27374 -- SubSeven backdoor probe.  Sub7 lets a remote individual transparently control your PC -- most importantly, it turns your workstation into a DDoS client.  Bloody IRC kids...<br><br>The UDP requests don't mean much to me either.  Possibly another worm, but possibly leftover UDP deliveries from a gaming server?<br><br>Sounds like you should check out the <A HREF="http://isc.incidents.org/">Internet Storm Centre</A> sometime.  Incredibly useful for how simple it is.<br><br>EDIT: Figured out what some of the ports were.<br><SMALL>--<br>Making life hard for others since 1977.</SMALL><br><i>[text was edited by author 2003-09-24 00:19:57]</i>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8047828</guid>
<pubDate>Tue, 23 Sep 2003 20:54:59 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8047793</link>
<description><![CDATA[<A HREF="/useremail/u/121311"><b>metrodust</b></A> : just got back in town and noticed this problem has finally started to hit me in the fact that my latency 5 times higher then it was before i went out of town. no trouble ticket in yet because i noticed it while at work and thought that maybe a router reset would fix it up.. but it didnt.. grrr!<br><br><i>[text was edited by author 2003-09-23 20:51:36]</i><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8047793</guid>
<pubDate>Tue, 23 Sep 2003 20:49:24 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8040923</link>
<description><![CDATA[<A HREF="/useremail/u/873863"><b>GamingGirl</b></A> : It looks like the TCP requests are all wanting port 135 with the occasional 445, 1433, 17300, NetBIOS session, HTTP and 27374. The UDP requests are looking for mainly (NetBIOS name) and two hits for port 1434. The ICMP request are ICMP Echo Requests. These results are for the last 1000 hits. This was from 3pm this afternoon until now (10:53pm). <br><br>I don't know if this answers what you need, but if not, let me know =).<br><i>[text was edited by author 2003-09-23 01:55:23]</i><br><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/8040923?c=434429&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="80068 bytes" WIDTH=600 HEIGHT=344 SRC="/r0/download/434429.thumb600~682f385b53d1fbe0572c0d625df10bd3/Firewall.JPG/thumb.jpg" ALT="Click for full size"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8040923</guid>
<pubDate>Tue, 23 Sep 2003 01:53:59 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8040854</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : List off some firewall entries, port numbers (src+dst) and protocols and I'll probably be able to tell you what's what.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8040854</guid>
<pubDate>Tue, 23 Sep 2003 01:38:28 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8040794</link>
<description><![CDATA[<A HREF="/useremail/u/637997"><b>macmouse</b></A> : Although I haven't managed with anything this large scale, I can give you my own little expierence...<br><br>Ok, Back in the day, I ran an game (counter-strike) server on my good 'ol pentium 200 linux box. w/64MB ram. It started as an NAT/ipmasq machine (before those router boxes are now so cheap) and grew into an catch all  for misc computer stuff...<br><br>Anyway, this "little computer that could" was running an half-life dedicated server in linux. I was actually able to get as far as 10 players, when finnaly I maxed out all CPU capacity on the machine.  The problem wasn't with bandwith (it was an local LAN game) but latency (ping) dropped like an rock. I'm not talking about just latency in game- If I ran an ping to the machine through the 100bt network, I would get 500ms+ pings! From what I'm figuring, the cpu (io bus) was so busy that all of the IO devices (like network card) had to sit and *wait* until the cpu was free to then be able to process the information. <br><br>I would not be suprised under extreme conditions that this could result in packet loss. The network card has to wait so long that the computer on the other end "gives up".<br><br>In the end, an router (cisco) is an computer and specialized software and an *lot* of io (network) ports. Ethernet,fiber,dsl what-have-you. So there was simply so much stuff going through that the "cpu" in the router got full, and that was that.<br><br>Also (somewhat reading between the lines), kat pretty much said that the POP's were at capacity (more or less) and they were going to have to upgraded. So, with an sudden increase of network activity (virus/torjans, or even heck just a bunch of new users) was/is enough to push it over the edge.<br><br>Simular things have happened in the past with other companies *cough* comcast *cough* so speakeasy isn't alone. To their credit, they are *telling* us whats wrong and that they are working on it. With comcast/attbi/@home, they said *nothing* and that was "just the way it is" and *eventually* things would "magically" start working again, with no explanation.<br><br>I hope that answers your question :).]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8040794</guid>
<pubDate>Tue, 23 Sep 2003 01:25:17 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8040785</link>
<description><![CDATA[<A HREF="/useremail/u/873863"><b>GamingGirl</b></A> :  <BLOCKQUOTE><SMALL>said by Carl F:</SMALL><HR>   <br>BTW, GamingGirl, is your upload stable enough for you to game reliably?<br><br>Cheers,<br><br>Carl F.<br> <HR></BLOCKQUOTE><br><br>It used to be awesome. I would get stable 55-65 pings to the server I play on in San Antonio. As it stands now, I still see occasional dropped packets. PL will spike to 30% from zero but only on occasion whereas I was seeing consistent PL for the first few weeks of Sept. I do see increased latency compared to the first six months of my service but there's not much I can do regarding that as it's a "best effort" service. I blame the latency on my second hop since results on each hop thereafter are solid and rarely, if ever, fluctuate. My ping plotter looks much like it did before but without the heavy red areas. That second hop has some serious ping spike issues.<br><br>I did a lot of ftp transfers just last night though and my upload is very steady around 650 up (I am on the 1.5/768 plan).<br><br>As far as gaming, I was thoroughly pleased with my line during the first six months and now I'm just satisfied and hoping that whatever changed will reverse itself and go back to normal when these upgrades take place. <br><br>Regarding the worms... I am seeing serious "ping requests" on my firewall, upwards of 400 over a 3 hour period (like whoa!). These are all ICMP packets with the occasional TCP and UDP requests for certain ports.... I don't know if that makes sense (I'm not that technically inclined =p ) but I do see wayyy more hits than I ever have before. A lot come from users on the speakeasy network (about half) and the rest are from other sources. Does anybody know why I keep getting hit like that? Is it indeed caused by the worms out there?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8040785</guid>
<pubDate>Tue, 23 Sep 2003 01:23:08 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8039879</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : Hi jmberry -<br><br>Kat said several posts back that they've reworked their processes to improve communication between engineering and tech support.<br><br>Sounds from your post, much to my astonishment, that first tier CS is still working off the same old script.<br><br>Good luck,<br><br>Carl F.<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8039879</guid>
<pubDate>Mon, 22 Sep 2003 23:22:52 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8037814</link>
<description><![CDATA[<A HREF="/useremail/u/841025"><b>jmberry</b></A> : While I'm glad I read through this entire thread, I'd have been a lot happier if more of this information had been shared w/me via the number of phone calls/emails/TT's I've submitted.<br><br>I'm in the last couple of days of my eval period for a T1, and am doing my best to come to the right decision in whether or not I am going to continue past that period with Speakeasy.  I've heard (and read) a lot of very positive things about them, but am having issues with a T1 line having a 100ms lag on its first hop....<br><br>~JMB]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8037814</guid>
<pubDate>Mon, 22 Sep 2003 20:05:47 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8037443</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :    <br>Hi Kat -<br><br>I can see, and very much appreciate, that you're working hard to be responsive.  Let me see if I can boil it down to a single question that I'd like to see answered in enough engineering detail that it makes some sense to me.<br><br>You said that Blaster et al. caused a .4X to .5X increase in traffic.  I measured a .5X decrease in bandwidth on both download and upload.  But I measured a 100X increase in variability (latencies, duration of stall events, etc.)<br><br>This is way out of whack, a very weird pair of symptoms.  If I were to graph this, the relationship between traffic increase and bandwidth decrease would be linear, .5X demand increase, .5X bandwidth decrease.  Yet the relationship between traffic increase and service stability and reliability would look like an exponential runaway or an asymptote, .5X demand increase, 100X reliability decrease.<br><br>If bandwidth were also collapsing nonlinearly, I would say that the traffic queueing management was thrashing terribly, with intermittent queue overflows: Kind of like the disk thrashing, the slowdown and the intermittent app failure that occurs when apps start page swapping like crazy.  But all that thrashing takes real-time.  The slowdown of applications goes nonlinear well before app failure occurs.  Yet the traffic slowdown, the loss of bandwidth stayed linear, so two orders of magnitude more thrashing still took place in a linearly increased amount of time.<br><br>How did download and upload bandwidth decrease linearly, but service reliability decrease exponentially/asymptotically, especially if, as you've repeated many times, there was no form of traffic throttling in force?<br><br>If, as Customer Experience Manager, this is beyond your expertise to answer in detail--it would certainly be beyond my expertise, as a real-time embedded engineer with negligible networking experience--could you please bring one of your network architects into the loop to answer this?<br><br>Thanks,<br><br>Carl F.<br><br><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8037443</guid>
<pubDate>Mon, 22 Sep 2003 19:29:48 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8036979</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> : or Seattle?....tomorrow is the one month anniversary of my trouble ticket being open for this issue.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8036979</guid>
<pubDate>Mon, 22 Sep 2003 18:46:42 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8036961</link>
<description><![CDATA[<A HREF="/useremail/u/169031"><b>falkclan</b></A> : any further information on the Chicago POP?<br><small>--<br>Alan Falk</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8036961</guid>
<pubDate>Mon, 22 Sep 2003 18:44:22 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8035299</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : I'm not sure what additional information you're looking for, but the issue is a hardware max-out on the number of packets per second that two of the routers in our SFO POP could process.  We alleviated this issue by moving about 40% of the customers on these routers over to another router with considerably less load.<br><br>We don't consider this issue closed as we're still seeing about 1 - 3% packet loss at this POP, depending on the time of day.  As I posted before, our Engineering team is continuing to investigate alternate improvements in the interim prior to the complete upgrade later this year.<br><br>Again, we made absolutely no changes to our SFO POP - have done no work on the impending complete upgrade scheduled for this fall.  This issue was caused by our routers inability to handle the extreme increase in the number of packets per second as the result of recent Internet worms, which are still having a significant impact.  Our abuse team is notifying and unbinding folks as appropriate in order to minimize our customers' contribution to this problem.<br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8035299</guid>
<pubDate>Mon, 22 Sep 2003 15:30:10 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8029305</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :    <br>I'd also like to know what was wrong and what they did to fix it.<br><br>Could just be that they undid whatever it is that they did--or started to do--about a month ago, when my download streams started to collapse with much higher frequency.  After all, we're all reporting that we're more or less back where we were.<br><br>Sounds to me like more of an 'Undo' than an 'Upgrade'.<br><br>BTW, GamingGirl, is your upload stable enough for you to game reliably?<br><br>Cheers,<br><br>Carl F.<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8029305</guid>
<pubDate>Sun, 21 Sep 2003 21:18:51 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8028940</link>
<description><![CDATA[<A HREF="/useremail/u/873863"><b>GamingGirl</b></A> : Yeah, other than extreme ping spikes on my second hop, I am seeing a whole lot of improvement. My packet loss is minimal and other than the ping spikes, I'm happy with it =). I also would like to know what they tinkered with to fix it as I'm curious that way. I cannot wait until it's 100% back to the way it was but for the meantime this will satisfy me =).]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8028940</guid>
<pubDate>Sun, 21 Sep 2003 20:44:25 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8027902</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Wow.  I switched over to the ADSL line this morning to see how things were, and to use it while at work throughout the day.  The graph is for <B>SUNDAY</B>, which means people are quite a bit less likely to be pounding on the network as much as during Mon-Fri.<br><br>I'm very impressed.  The spikes/ramping you see in the graph are <I><B>_entirely_</B></I> caused by me (streaming mp3s + remote desktop + file transfers); latency to my gateway has an average of 28ms, but that's simply because I did a lot more streaming today than I usually do.  I'd say the average is more like 11-13ms.  No socket stalling or Remote Desktop drops were encountered.<br><br>There is still some packet loss, but like Carl F. said, things are looking up for SFO.  PLEASE do not consider this issue closed, however -- things are just looking better, that's all.<br><br>I'll have to see how the rest of the work week looks.  If it stays this way.<br><br>P.S. -- Can we get a statement in regards to what exactly was the (primary) cause of this?  Routers?  Oversaturation?  Equipment failure?  Aliens?  :-)<br><small>--<br>Making life hard for others since 1977.</small><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/8027902?c=433474&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="19376 bytes" WIDTH=600 HEIGHT=475 SRC="/r0/download/433474.thumb600~11e661096939eb67d7ba9de277489d3c/se_happy_1.png/thumb.jpg" ALT="Click for full size"></A><br>SFO, 09/21</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8027902</guid>
<pubDate>Sun, 21 Sep 2003 18:33:21 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8015541</link>
<description><![CDATA[<A HREF="/useremail/u/585933"><b>sh0V3L</b></A> : asdfghj !!!! i have sdsl and it may aswell be cable the way it is now .................]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8015541</guid>
<pubDate>Sat, 20 Sep 2003 02:06:22 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8013138</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : We performed some upgrades to the SEA POP on Wednesday, but the full upgrade isn't scheduled for a couple more weeks, I believe.  We are working on an interim solution for this and the NYC POP, however.<br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8013138</guid>
<pubDate>Fri, 19 Sep 2003 20:12:16 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8012917</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> : Kat-<br><br>I got a call from tech support last week that stated the Seattle POP would be upgraded on this past Wednesday(9/17).  Did that happen or is it on hold?<br><br>Self]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8012917</guid>
<pubDate>Fri, 19 Sep 2003 19:46:05 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8012543</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :    <br>15:20 PDT<br><br>So, my stream from KWAX (64Kbps) went to hell in a hand-<br>basket, but my stream from KUAT (132Kbps) seemed fine.<br><br>So I decided to run the characterization test I ran a<br>couple of weeks ago, at almost the exact same time of<br>day, to see more exactly where things stand.<br><br>For those of you who haven't looked at the thread on<br>SpeakEasy's own forums (to which I supplied a link on<br>page 4 of this DslForum thread), here's the procedure<br>I use.<br><br>On the SFO POP, SpeakEasy provides an applet that <br>instruments your current bandwidth.  Because it's an<br>instantaneous measure, no single measurement will be<br>all that accurate.  Moreover, it may have some additional<br>inefficiencies that causes it to underestimate bandwidth<br>by 10% or maybe even 20%.  (For example, I'm unclear if<br>it counts IP packet headers.)<br><br>That said, this applet is a fine tool if you take <br>several samples back-to-back.  20 samples gives fine<br>statistical power.  It's not a good tool for tweaking<br>10% or 20%.  It's a great tool for estimating orders<br>of magnitude, that is, powers of 10.<br><br>The average bandwidth over 20 samples is fine for <br>estimating the order of magnitude of bandwidth delivered, <br>that is, am I getting closer to 600Kbps or 60Kbps.  <br><br>The standard deviation over 20 samples is a great way<br>to estimate the order of magnitude of variability of <br>bandwidth delivery, that is, am I getting X Kbps,<br>plus-or-minus 10Kbps, 100Kbps or 1000Kbps.<br><br>For a 768/384 service like I have, the following apply.<br>Plus-or-minus 10Kbps is a very even stream, and should<br>be suitable for almost any purpose.  Plus-or-minus<br>100Kbps is adequate only for low-bandwidth streaming,<br>and may be completely unsuitable for gaming.  Plus-or-minus<br>1000Kbps is unsuitable for any real-time interactive<br>use.<br><br>What I'm going to show is 2 times the standard deviation,<br>because 97% of all packets should fall within this<br>plus-or-minus range.<br><br><br>SFO POP, 20 back-to-back samples, 768/384 Straight-Up<br><br>TWO WEEKS AGO, 6sep03 14:15 PDT<br>=====================================<br>Average DOWN: 345 Kbps<br>Average UP: 293 Kbps<br><br>2 x Std. Deviation DOWN: +/- 184 Kbps<br>2 x Std. Deviation UP: +/- 1742 Kbps (NOT a typo!!)<br><br>TODAY, 19sep03 15:00 PDT<br>======================================<br>Average DOWN: 633 Kbps<br>Average UP: 640 Kbps<br><br>2 x Std. Deviation DOWN: +/- 26 Kbps<br>2 x Std. Deviation UP: +/- 300 Kbps<br><br><br>SUMMARY:  Twice as much bandwidth is being delivered,<br>in both directions, with almost an order of magnitude less<br>variability.  The download side variability should be<br>reduced farther, though not as a highest priority<br>activity.  The upload side still shows too much variability<br>for gamers, video conferencing and the like.<br><br>For my purposes, IF THIS IS STABLE, I'm in decent shape,<br>and should move down the triage list--but NOT off it.<br>Gamers and other interactive users should not allow<br>SpeakEasy tech support to use the strength of my report,<br>based on my download centered usage, to b.s. them that<br>everything is much better on the SFO POP, and what's<br>their problem.  Upload bandwidth is good, but variability<br>is still unacceptable.<br><br>Cheers,<br><br>Carl F.<br>San Francisco<br><br><br><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8012543</guid>
<pubDate>Fri, 19 Sep 2003 18:57:54 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8012312</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : We are continuing to work on this issue - the majority of our customers in SFO, LAX and CHI areas have reported a much improved experience.  I have a couple of reports otherwise and our Engineering team is investigating more interim improvements to all POPs, specifically SEA and NYC, that can be made prior to the full POP upgrades already scheduled.<br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8012312</guid>
<pubDate>Fri, 19 Sep 2003 18:23:59 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8010951</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :   <br>12:15 PDT<br><br>I've been streaming 176Kbps from UMich for almost<br>four hours now.<br><br>Packet Loss is sitting at about 1%.  Unrecoverable<br>packets, that is, lost packets that RealPlayer<br>retries but cannot recover in time, is sitting at<br>about .1%.<br><br>This is about one order of magnitude better than the<br>terrible performance of a week or two ago.<br><br>This is adequate performance, that is, RealPlayer<br>doesn't automatically downgrade my stream to a lower<br>bitrate.  However, it's also not stellar, as I should<br>have lots of head-room on a 768/384 Straight Up,<br>with no other network activity in progress.<br><br>I can tell that it's not yet as good as it used to be,<br>because of the frequency with which I'm hearing the<br>stream glitch, every time a packet is unrecoverable.<br>In a 24/7 classical music stream, the glitches are<br>unmistakably audible.  But I can live with this for a while,<br>in terms of SpeakEasy's triage, as long as: (1) It doesn't<br>get worse from here, and (2) SpeakEasy knows that they need <br>to do another iteration of performance improvements, before <br>the SFO POP will be whole.<br><br>More later,<br><br>Carl F.<br><br><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8010951</guid>
<pubDate>Fri, 19 Sep 2003 15:33:05 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8010781</link>
<description><![CDATA[<A HREF="/useremail/u/585933"><b>sh0V3L</b></A> : I still see zer0 improvement check this out &raquo;<A HREF="/quality/nil/1166407">/quality/nil/1166407</A><br><br>Im really getting tired of this i get email from tech support that pretty much calls me a liar <br><br>After the maintainence late tuesday night, we're hearing lots of reports that the problems in your area have much improved.         ("WEEEEEEEEE!!!!!!!")<br><br>Port Status:  Up<br>Actual Port Speed: 768 kbps<br>Margin: 15.5 dB<br>Upstream Cells Received from CPE:  67 ( 943187633 )<br>Downstream Cells Transmitted to CPE: 184 ( 1461619541 )<br>ATM HEC Errors: 0 ( 7998 )<br>Upstream Line Errors: 0 ( 958 )<br>Downstream Line Errors: 0 ( 667 )<br>Time Since Snapshot Counters Reset: <br>3 Min. 13 Sec.<br><br>Are you still seeing problems when you have just one computer plugged directly into your modem?<br><br>ANS : my modem has 1 wan port 1 lan um so ya . WTF  does that have to do with pnaps lousy routing<br><br>Could you show me the 18 hop traceroute to yahoo?<br>----------------------------------------------------------------------<br><br>Thank you for your business,......... heh<br><br>The Speakeasy Crew<br>800.556.5829<br>one of my many imediate replys<br><br>Microsoft Windows 2000 [Version 5.00.2195]<br>(C) Copyright 1985-2000 Microsoft Corp.<br><br>C:\>tracert www.yahoo.com<br><br>Tracing route to www.yahoo.akadns.net [66.218.71.93]<br>over a maximum of 30 hops:<br><br>  1    20 ms    10 ms    20 ms  dsl092-028-001.sfo4.dsl.speakeasy.net<br>[66.92.28.1]<br>  2    20 ms    10 ms    20 ms  border5.g3-4.speakeasy-29.sfo.pnap.net<br>[63.251.53.2<br>  3    10 ms    20 ms    20 ms  core2.ge2-0-bbnet2.sfo.pnap.net<br>[63.251.63.66]<br>  4    10 ms    20 ms    20 ms  iar1-so-2-2-0.SanFrancisco.cw.net<br>[208.173.173.9]<br>  5    10 ms    20 ms    20 ms  acr2-loopback.SanFrancisco.cw.net<br>[206.24.210.62]<br>  6    20 ms    30 ms    20 ms  bpr2-as0-0.SanJoseEquinix.cw.net<br>[206.24.211.42]<br>  7     *       20 ms    30 ms  bpr1-ae0.SanJoseEquinix.cw.net<br>[208.173.54.85]<br>  8    20 ms    30 ms    30 ms  208.173.54.74<br>  9    20 ms    20 ms    30 ms  so-5-0-0.gar1.SanJose1.level3.net<br>[209.244.3.137]<br> 10    20 ms    20 ms    20 ms  gige9-0.ipcolo3.SanJose1.Level3.net<br>[64.159.2.9]<br> 11   140 ms   220 ms   211 ms  unknown.Level3.net [64.152.69.30]<br> 12     *        *        *     Request timed out.<br> 13     *        *        *     Request timed out.<br> 14     *        *        *     Request timed out.<br> 15     *        *        *     Request timed out.<br> 16     *        *        *     Request timed out.<br> 17     *        *        *     Request timed out.<br> 18     *        *        *     Request timed out.<br> 19     *        *        *     Request timed out.<br> 20     *        *        *     Request timed out.<br> 21     *        *        *     Request timed out.<br> 22     *        *        *     Request timed out.<br> 23     *        *        *     Request timed out.<br> 24     *        *        *     Request timed out.<br> 25     *        *        *     Request timed out.<br> 26     *        *        *     Request timed out.<br> 27     *        *        *     Request timed out.<br> 28     *        *        *     Request timed out.<br> 29     *        *        *     Request timed out.<br> 30     *        *        *     Request timed out.<br><br>Trace complete.<br> <br>Ya Speakeasy Thats Excellent routing  and such an improvement  looks like you made a liar out of me !!!!!!!!...........NOT!!!!!!!! <br><br>Just fix it!!!!  this issue is  so old now ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8010781</guid>
<pubDate>Fri, 19 Sep 2003 15:07:06 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8009105</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : 8:00 PDT<br><br>It's early in the morning just yet, but things seem fine.<br>I'm streaming 176Kbps from UMich as I write.<br><br>Also, I'm realizing that what I reported last night as<br>stalling is likely to be the way a RealStream does flow<br>control, in some configurations.<br><br>As such, I'm getting progressively more optimistic.  If<br>this stabilizes, the upgrade will have yielded a real<br>QOS improvement.<br><br>More later,<br><br>Carl F.<br>San Francisco<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8009105</guid>
<pubDate>Fri, 19 Sep 2003 11:16:51 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8008456</link>
<description><![CDATA[<A HREF="/useremail/u/457359"><b>MrCoal</b></A> : Last night there was some real improvement in the Chicago POP. Then at 3:06am, the route changed, <B>ping times doubled</B> and packet loss started again.<div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/8008456?c=432009&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="19872 bytes" WIDTH=600 HEIGHT=435 SRC="/r0/download/432009.thumb600~aba87fe52634a12c13b3888f14a28e99/pingplot.gif/thumb.jpg" ALT="Click for full size"></A><br>Chicago POP</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8008456</guid>
<pubDate>Fri, 19 Sep 2003 09:34:43 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8007456</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : $!(*&$(*@  I'm SO GLAD someone is also experiencing the stalling.  The packet loss is one thing, but I thought I was the only one experiencing socket stalls.<br><br>I've been on my cable modem since my last post, and despite the flippant latency, I've had nothing but a solid connection.  *sigh*<br><br>Here's hoping Kat and engineering fix what's broke!  *thumbs up*<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8007456</guid>
<pubDate>Fri, 19 Sep 2003 03:14:56 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8007133</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : here are the only places that i see any sort of packet loss... yes, i did happen to ping the router itself for my pop... cause it resolves to sea.speakeasy.net, and i have no clue where gate.tailie.net is... :S<br><SMALL>--<br>I post for myself, from myself. Statements made do not necessarily reflect the views of my employer, Charter Communications, or any of its subsidiaries.</SMALL><br><i>[text was edited by author 2003-09-19 01:42:26]</i><br><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/8007133?c=431895&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="16887 bytes" WIDTH=600 HEIGHT=444 SRC="/r0/download/431895.thumb600~64220e282134cc52c22eddc3b902c0c9/lax.speakeasy.net.png/thumb.jpg" ALT="Click for full size"></A><br>jango.outerfx.net to lax.speakeasy.net</TD></TR><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/8007133?c=431896&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="9992 bytes" WIDTH=600 HEIGHT=390 SRC="/r0/download/431896.thumb600~2912b03c0a168c9c9598d84e49226742/pdx.speakeasy.net.png/thumb.jpg" ALT="Click for full size"></A><br>jango.outerfx.net to pdx.speakeasy.net (sea.speakeasy.net)</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8007133</guid>
<pubDate>Fri, 19 Sep 2003 01:41:16 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8007034</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :    <br>More data:<br><br>I opened a stream to UTenn at 176Kbps.  Partial collapse<br>at some point to 132Kbps.<br><br>At 22:15 PDT, when I'm writing this, I'm seeing 1-2 sec.<br>stalls, very reliably every 10 seconds.  That is, duty<br>cycle of 80% transmission and 20% dead time.  Fetch-ahead<br>seems to be good enough that this does not result in<br>horrible degradation, but still some.<br><br>On the other hand, earlier today, I got almost flawless<br>transmission of a 96Kbps stream from Budapest, Hungary.<br><br>I'm not sure how to interpret these unsystematically<br>collected data points, but perhaps they will correlate<br>with QOS monitoring.<br><br>Cheers,<br><br>Carl F.<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8007034</guid>
<pubDate>Fri, 19 Sep 2003 01:21:59 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8004200</link>
<description><![CDATA[<A HREF="/useremail/u/458555"><b>ykrad</b></A> : Ditto.  Although my problems haven't been as extensive (or extreme) as many others, it's still irritating to still have to point this out.<br><br>line quality test fails coming from both west and east coasts:<br>&raquo;<A HREF="/quality/nil/1165758">/quality/nil/1165758</A>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8004200</guid>
<pubDate>Thu, 18 Sep 2003 20:24:42 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8003803</link>
<description><![CDATA[<A HREF="/useremail/u/696918"><b>Endorphine</b></A> : Same here.<br>I haven't seen any changes to the Seattle POP at all :(<br><br>Marc<div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/8003803?c=431622&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="30490 bytes" WIDTH=600 HEIGHT=474 SRC="/r0/download/431622.thumb600~7d789335cca3595b39b5bcd6218413ce/ping.symantec.com.png/thumb.jpg" ALT="Click for full size"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8003803</guid>
<pubDate>Thu, 18 Sep 2003 19:45:30 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8003379</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : mine is doing fine, but for some odd reason when i do a tracert to pdx.speakeasy.net, it comes back as sea.speakeasy.net...<br><br>also what does gate.tallie.net have to do with my connection??<br><br>i don't see this on anyone else's ping plotter posts... unless you guys are skipping the first hop... which i never do...<br><br>so where is the PDX pop? acutally in seattle??<br><small>--<br>I post for myself, from myself. Statements made do not necessarily reflect the views of my employer, Charter Communications, or any of its subsidiaries.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8003379</guid>
<pubDate>Thu, 18 Sep 2003 19:04:54 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8002754</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> : I'm not sure if the Seattle POP received any upgrades or made any changes last night, but my connection remains as bad as previously noted in this thread.<br><br>Self]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8002754</guid>
<pubDate>Thu, 18 Sep 2003 18:04:20 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8001164</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :    <br>So here's another interesting data point.<br><br>KUAT, our preferred 132Kbps stream, has just gone into<br>fund-raising mode, so we've switched to our preferred<br>fallback, KWAX which offers a 64Kbps stream.<br><br>UDP packet loss has jumped up to almost 1%, 10x greater<br>than with KUAT, but still well within what RealPlayer's<br>packet recovery protocol can sustain.<br><br>BUT, KWAX has always been a more heavily subscribed and<br>somewhat flakier stream.<br><br>So, I'm beginning to feel like I'm getting back to the<br>point where I can see the internet beyond SpeakEasy,<br>warts and all, instead of constantly bumping up against <br>problems at SpeakEasy that obscured the internet from view.<br><br>Again, I'm looking for several days of stability before<br>I turn off the high-frequency acquisition radar and go <br>back to low-frequency search mode.  Paradoxically, however,<br>this performance decrement in a place where I'd expect<br>it is another good early sign.<br><br>Cheers,<br><br>Carl F.<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8001164</guid>
<pubDate>Thu, 18 Sep 2003 14:37:31 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8000934</link>
<description><![CDATA[<A HREF="/useremail/u/873863"><b>GamingGirl</b></A> : I can't wait to get home to see if there is improvement on my line. I actually heard from Speakeasy last night on my ticket and they ran tests and saw the packet loss for themselves. That made me feel a little better that they did acknowledge that I do have problems on my line. I tried to game a little last night and it was horrid... I was experiencing 10-15% packet loss so half of my shots wouldn't fire and I kept falling off of cliffs. This may have been previous to any work they had scheduled though. I cannot wait to be able to get a good game on again =).]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8000934</guid>
<pubDate>Thu, 18 Sep 2003 14:05:13 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8000921</link>
<description><![CDATA[<A HREF="/useremail/u/595666"><b>whiteshp</b></A> : Well I didn't notice any problems till today.  From 12:30 till 4AM service to my SDSL was mostly out (longest outage ever for me).  It has been up mostly today but still a LOT of little brief outages all through the day.  I sure hope they get this new hardware/routing fixed soon! :/]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8000921</guid>
<pubDate>Thu, 18 Sep 2003 14:02:46 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8000724</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> :     <br>So far today, service looks much improved.  Based on 4 <br>hours of streaming, UDP packet loss is around .01% (32<br>packets in 210,000), as opposed to 6% two weeks ago.<br>I also ran a concurrent 8MB download, which sustained<br>60KBytes/sec, without adversely impacting the stream.<br><br>It's still a bit early in the morning, just yet.<br>I'm holding my breath to see if this remains stable,<br>but it's definitely a good first step of forward progress.<br><br>More later,<br><br>Carl F.<br>San Francisco<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8000724</guid>
<pubDate>Thu, 18 Sep 2003 13:40:34 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8000411</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : Our engineering team is currently working with the vendor on this.<br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8000411</guid>
<pubDate>Thu, 18 Sep 2003 13:04:42 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,8000086</link>
<description><![CDATA[<A HREF="/useremail/u/534908"><b>surtin</b></A> :  <BLOCKQUOTE><SMALL>said by  MrCoal <A HREF="/useremail/u/457359"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>Well, the maintenance on the Chicago POP has made packet loss WORSE<HR></BLOCKQUOTE><br><br>Yup it sure did, I'm especially upset since I didn't have any problem at all, now I'm downloading at at best 2kb/s now (early in the morning it was 5kb/s). This is pretty much like bein' on dial-up... oh wait I even downloaded faster when I WAS on dial-up.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,8000086</guid>
<pubDate>Thu, 18 Sep 2003 12:24:58 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7999398</link>
<description><![CDATA[<A HREF="/useremail/u/457359"><b>MrCoal</b></A> : Well, the maintenance on the Chicago POP has made packet loss WORSE (I am posting this on dial-up because I cannot connect via DSL)<br><br>I have had packet loss/connection problems for at least four months and Speakeasy has a <I>very</I> limited time to fix this before I cancel service.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7999398</guid>
<pubDate>Thu, 18 Sep 2003 10:51:02 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7997332</link>
<description><![CDATA[<A HREF="/useremail/u/585933"><b>sh0V3L</b></A> : well i dont know what they did or if anything was done im still getting spikes up to 300 ms off the sfo pnap  routing is still screwed up  i say lies all lies sorry thats just how it asppears to me  i would post a tracert or ping platter but i see no use as i have posted many and speakeasy is well aware of the problem that being   PNAP i feel the nastys coming on so ill stop here ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7997332</guid>
<pubDate>Thu, 18 Sep 2003 00:47:05 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7996689</link>
<description><![CDATA[<A HREF="/useremail/u/696918"><b>Endorphine</b></A> : As you may have noticed I said "over the life of the worm", I am aware the chart is over a month old.  Just was pointing out the severity of the infection.<br><br>If you want recent data on port attacks a good site is the Internet Storm Center:  &raquo;<A HREF="http://isc.incidents.org/" >isc.incidents.org/</A><br><br>Marc :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7996689</guid>
<pubDate>Wed, 17 Sep 2003 23:18:30 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7996199</link>
<description><![CDATA[<A HREF="/useremail/u/588258"><b>borborpa</b></A> : FYI the graph on hackerwatch is a month old... :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7996199</guid>
<pubDate>Wed, 17 Sep 2003 22:25:23 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7995897</link>
<description><![CDATA[<A HREF="/useremail/u/696918"><b>Endorphine</b></A> : Kat,<br><br>Thanks again for the update on the maintenance updates.  I would agree that there is quite a bit of worm traffic going on.  My router catches 300+ hits alone on port 135 & 137.  And this is on just my IP address!?!?!  Last I checked there were over 1.5 million computers infected over the life of the worms (68,000 infections each hour!).  If you don't believe me check this out:  &raquo;<A HREF="http://www.hackerwatch.org/checkup/graph.asp" >www.hackerwatch.org/checkup/graph.asp</A><br><br>Any information on when the Seattle routers were going to be upgraded?  I though you said previous that it was going to be tonight?<br><br>Thanks again.<br><br>Marc<br><I>[text was edited by author 2003-09-17 21:56:22]</I><br><br><i>[text was edited by author 2003-09-17 21:57:02]</i><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7995897?c=430919&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="28596 bytes" WIDTH=600 HEIGHT=436 SRC="/r0/download/430919.thumb600~7d789335cca3595b39b5bcd6218413ce/ping.symantec.com.png/thumb.jpg" ALT="Click for full size"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7995897</guid>
<pubDate>Wed, 17 Sep 2003 21:54:54 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7995402</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : Hi Kat -<br><br>I just got home and brought up my 132Kbps stream from KUAT.<br><br>I'll check-in in the morning with my observations.  But<br>I also don't want to call this closed until I've been<br>stable for several days.<br><br>Also, for my money, you don't owe anyone any apologies.<br>As I said, you do your job very well, howsoever you<br>choose to categorize it, PR or otherwise.  I hope you <br>found me to be pursuing my legitimate interests in a<br>fair-minded and reasonable fashion, howsoever challenging<br>that may have made your life on any given day.<br><br>Your frustration was understandable.  At the same time, I<br>didn't want people to forget that this is a business<br>relationship, not a personal one, and so our sympathy<br>for you personally should not be allowed to translate to<br>sympathy and a free pass for SpeakEasy as a whole.  That<br>said, I never took this personally, and I hope you didn't <br>either.  It's been good and educating to do business with <br>you.<br><br>I'm definitely heartened to hear that your CEO has been<br>tracking this thread.  I hope that means that he realizes<br>that he owes you an apology for keeping you on a tight<br>leash in an awkward position.  Oh, and a week of comp-time,<br>totally.  At least. ;-)  (I also think he owes whomever you <br>report to directly a good wire-brushing behind the ears.)<br><br>Thanks for hanging in there with a high-stress encounter<br>for all of us.  Relationships are like that sometimes.<br>Yet SpeakEasy will move higher on my list as a vendor than<br>it was before all this, if I can look back and say to<br>myself, honestly, They learned something, they let their<br>customers make an impact, and service is better than the <br>seemingly halcyon days before the problem surfaced.<br><br>Cheers,<br><br>Carl F.<br>San Francisco<br> ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7995402</guid>
<pubDate>Wed, 17 Sep 2003 21:05:52 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7995222</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : Just finished meeting with Engineering - quick update:<br><br>Tonight we'll be performing maintenance in CHI and LAX that will improve performance for circuits in Chicago, Detroit, Dayton, Los Angeles and San Diego.<br><br>I'm compiling information on NYC - I have two recorded issues (yoonix and bhan21), and will gather data from our ticket system tomorrow to determine what kind of an impact we're seeing there.  Upgrades to NYC are still being discussed.<br><br>At this time, we have no reports on our other POPs or NAPs, but are continuing to monitor.<br><br>We have sent out another round of notices on the Welchia worm and will be assessing reported IPs for another notification within the next couple of days.<br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7995222</guid>
<pubDate>Wed, 17 Sep 2003 20:47:46 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7995138</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : people, just an FYI, the PDX Pop, is not being affected by this... it was till we had the outage while ago, i have been doing tests along with all of you to your own pops and the monitoring is still going on from my end :)<br><br>heh, NYC, CHI, LAX all are being tracked through my POP, PDX...<br><br>I have very little or no packetloss from my POP, sorry for making some of you confused... :|<br><br>as for communicating with the other pops, well i will post that info in a couple of hours :)<br><SMALL>--<br>I post for myself, from myself. Statements made do not necessarily reflect the views of my employer, Charter Communications, or any of its subsidiaries.</SMALL><br><i>[text was edited by author 2003-09-17 20:37:17]</i><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7995138</guid>
<pubDate>Wed, 17 Sep 2003 20:36:13 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7994924</link>
<description><![CDATA[<A HREF="/useremail/u/816633"><b>wattjg</b></A> : We've had *no* packet loss recorded by our monitoring software since 2330 PDT yesterday.  The software (mrtg) generates loss graphs on 1500 byte pings to the SFO POP.<br><br>We're in one of the 216 netblocks.<br><br>We're still observing and reporting quite a bit of W32.Welchia ICMP traffic, though.  It hasn't decreased much.<br><br>Jim]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7994924</guid>
<pubDate>Wed, 17 Sep 2003 20:12:55 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7994841</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : Bondman -<br><br>While the full upgrades to our POP will be completed in early next year, we will be making improvements ASAP to improve the performance of folks in the LAX, CHI and NYC POPs.  This is the information that I will provide tomorrow morning after my meeting with the Director of Engineering in a few minutes.  We are monitoring SFO to confirm that this morning's transition alleviated the packet loss there.  SFO was, by far, the most impacted POP.<br><br>Mike is definitely aware of the issues and this thread - and is working with me on a resolution for this.  I have addressed the issue of service credit for those that are experiencing severe service-impacting packet loss and will resolve this ASAP.<br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7994841</guid>
<pubDate>Wed, 17 Sep 2003 20:05:29 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7994581</link>
<description><![CDATA[<A HREF="/useremail/u/459309"><b>Bondman</b></A> : Kat:<br>  I appreciate the info you have given.  The concern I have is the July CEO update Speakeasy gave no time frame to fix the problems.  You mentioned the term several months.  I interpret that to mean 4 or more months away before all of this is done.  Shouldn't one get compensation for services paid for but not delivered.  I am very concerned with the announcement pushing for more customers before the proper service is in place.<br>&raquo;<A HREF="/shownews/33139">Little Fish, Big Pond</A><br>I am having major issues with browsing any time in the afternoon and evening hours.  Why are you (Speakeasy) not acknowledging that there are problems with the Speakeasy Network status by naming POPs involved other than the general Worm statement?  I have no complaints with you as a person trying to help people and you have personally helped me in the past.  I want Mike Apgar to personally see all of these postings about the poor quality of service Speakeasy is providing customers and to state why we should not get some compensation for services not delivered.<br><i>[text was edited by author 2003-09-17 19:41:42]</i>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7994581</guid>
<pubDate>Wed, 17 Sep 2003 19:41:08 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7994393</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : Hi all -<br><br>Update here on this issue:<br><br>The transition in the SFO POP is complete - if any customers in that POP reading this have the time to post information on their circuit's performance since 8AM PST, I'd be very interested to see what kind of impact on performance this has made.<br><br>The fact of the matter is, as referenced in my original post on this thread, the added load of the worm in August and early September maxed out equipment that we had already identified as in need of an upgrade.  For those of you that did not receive <A HREF="http://www.speakeasy.net/main.php?page=july03letter">this CEO update</A> that Mike Apgar wrote to all customers in July of this year, it details all of our impending network upgrades that will begin with Seattle and continue over the next several months, with upgrade priority based on both present capacity and POP load.  Additionally, the ADSL service upgrades we informed customers about a few weeks back will occur in tandem with these equipment upgrades.<br><br>I am meeting again with our Director of Engineering tonight to go over the interim upgrades that we will be making to our POPs in order to improve and/or maintain the service levels for our existing customers.  I will transmit a synopsis of this to all staff and post an update of it here tomorrow, most likely mid-morning.  <br><br>I regret that any of our customers felt that their experience and/or this issue was being neglected by Speakeasy and that we were not able to respond in a more visible manner sooner.  We are very much focused on resolving this problem in the short-term while we deploy the equipment improvements that will solve this problem in the long-term.  We have had some failures in communication between our engineers and support staff -- this morning we identified some ways in which we can improve this and I'm hopeful that these measures will be put into place ASAP to ensure that our front-line support staff is as pro-active and informative as possible if & when we are faced with a similar situation in the future.<br><br>Additionally, I'd like to apologize to anyone who interpreted my posts as self-righteous in any way - that was/is absolutely not my intention.  It does get frustrating to have to regularly defend whether or not I am providing accurate, honest and up-to-date information in a forum that I have participated in for over 2 years - but that's my baggage.  Also, my role with Speakeasy is not as Public Relations, so sometimes my tongue gets the best of me. In fact, that's why I quit doing PR. ;)<br><br>I'll post a more detailed update around our network improvements tomorrow.<br><br>Thanks,<br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7994393</guid>
<pubDate>Wed, 17 Sep 2003 19:22:03 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7991202</link>
<description><![CDATA[<A HREF="/useremail/u/457359"><b>MrCoal</b></A> : Here's my contibution. It's been this way 24 hours a day for <B>months!</B><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7991202?c=430544&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="24038 bytes" WIDTH=600 HEIGHT=484 SRC="/r0/download/430544.thumb600~aba87fe52634a12c13b3888f14a28e99/pingplot.gif/thumb.jpg" ALT="Click for full size"></A><br>Chicago POP</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7991202</guid>
<pubDate>Wed, 17 Sep 2003 13:15:12 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7989826</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : Hi Charter Pipeline Support Tech -<br><br>I agree absolutely that Kat Oak is in the difficult <br>position of being a PR soldier, executing the decisions<br>of others higher-up.  I have tried to say as clearly as<br>possible that I think she does her job very well.  Based<br>on her performance in this and SpeakEasy's own forums,<br>I'd hire her in a heartbeat for my own company, if I had<br>one.<br><br>For that reason, I really don't want to be a thorn in her<br>side.  I feel bad that circumstances place a good, <br>competent and diligent person like Kat between me and<br>the kind of information that SpeakEasy would share, if<br>it really meant to have the kind of relationships with<br>its customers that it says it has and values having.<br><br>At the same time, I do mean--and perhaps enjoy a little<br>too much--to be a thorn in the side of the greasy-pole-<br>climbing directors and VPs at SpeakEasy who are making all <br>the bone-headed decisions about how to do damage control, <br>and who are then hiding behind the good soldiers at <br>SpeakEasy like Kat and the first tier CS techs.<br><br>Unfortunately, the only way I know to put pressure on<br>senior management is to put back-pressure on PR spun by <br>people like Kat, who are the public face of SpeakEasy's <br>spin machine.  When people understand the techniques that <br>PR people use to look like they're doing their level best <br>to answer questions when in fact they're sharing precious <br>little information, the playing field between small <br>customer and big vendor gets a bit more leveled.<br><br>Kat is a nice and earnest person, not a sneering PR <br>asshole, so I feel bad that she's the target of my<br>backpressure--but not so bad that I'm willing to hang <br>back and accept protractedly poor service and feeble<br>explanations.<br><br>What I'd really like to see at this point is for the<br>responsible senior players at SpeakEasy to have the<br>integrity to get on-line themselves, instead of hiding<br>behind Kat and others.  I personally find it <br>unconscionable that her management has left Kat hanging<br>out to dry, while they position themselves to have their<br>bonuses and options packages grow.  But that's what<br>greasy pole climbers do: They clutch and crawl on top of<br>the bodies of the good people that they burn out, in their<br>overweening sense of entitlement to get to the top.<br><br>Cheers,<br><br>Carl F.<br><br><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7989826</guid>
<pubDate>Wed, 17 Sep 2003 10:01:45 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7989371</link>
<description><![CDATA[<A HREF="/useremail/u/194251"><b>derk</b></A> : It's 8:37AM and I am in Cleveland OH.  I go through a Cleveland NAP and through the Chicago POP.  <br><br>Ping statistics for 209.123.109.175:<br>    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),<br>Approximate round trip times in milli-seconds:<br>    Minimum = 49ms, Maximum = 49ms, Average = 49ms<br><br>I use either a 5260 Speedstream or Zyxel modem.  I agree that it looks like the Chicago POP is oversold.   I work at home and I have been experiencing the latency issue all week throughout the day.   <br><br>I am glad my binding contract is over with Speakeasy.  I am giving this problem a month before I switch to another alternative.   Well, all I can say is that this was great DSL while it lasted, but NOTHING lasts forever...<br><br>:(]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7989371</guid>
<pubDate>Wed, 17 Sep 2003 08:40:57 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7989152</link>
<description><![CDATA[<A HREF="/useremail/u/459309"><b>Bondman</b></A> : Kat:<br>   It is 7:15 in the morning in Southeast Michigan.  Below is my ping time for DET.Speakeasy.net this morning.<br><br>Ping statistics for 64.81.159.2:<br>    Packets: Sent = 73, Received = 73, Lost = 0 (0% loss),<br>Approximate round trip times in milli-seconds:<br>    Minimum = 14ms, Maximum = 22ms, Average = 16ms<br><br>I am using the same equipment etc.  I get 2 twice the ping times and some packet loss mid-day and in the evening.  I have been experiencing issues every night for the past couple of weeks.  Either the Chicago POP has been over sold, equipment is failing at higher stress levels or groups of users are coming on mid-day and evening are using excessive bandwidth.<br><i>[text was edited by author 2003-09-17 07:43:33]</i><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7989152</guid>
<pubDate>Wed, 17 Sep 2003 07:41:51 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7988667</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : I experienced too many random whacko latency/stalls of up to 10 seconds while RD'ing into home (worked great until about noon, obviously nothing changed on my end) throughout the day.  My day was from 07:00 until 17:00.<br><br>Came home around 17:30, and noted PP showing the usual heavy packet loss.  I spent my evening playing GBA (primarily) and chatting on Messenger, checking my Email at my co-lo off and on (stalling did not happen, but the packet loss was still there).  Back to the GBA for awhile, then decided to try to do some co-lo kernel work at around 23:30, shortly prior to bed.  Major stalls, a couple sockets never even came back (!).  PP shows nothing other than the usual behaviour at this time of night.<br><br>Just can't deal with it any longer.  Call me when the SFO fix is deployed; I'm still not giving up on SE yet, but they have until the end of the month to provide a full prognosis of what the actual problem is (oversaturation, flaky interfaces, evil Junipers (sorry, I cannot stand those bloody things; pure software routing on border and backbone routers is just plain wrong), packet kids, or whatever it might be).<br><br>Once I get a factual explanation, I'll probably stick around for another month after that, just to see if it's solved.  Otherwise, consider me gone before the end of the next billing cycle, as I'll move to SBC or DSL Extreme, as two people in my apt. complex (one in my building!) have DSL through those providers and their traceroutes are much more golden.<br><br>So I'm back to the cable modem for the next few days.  Flippant 25-75ms latency sucks for gaming or anything fun like that, but at least the connection is solid and there aren't stalling sockets, so at a bare minimum I can get some co-lo work done.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7988667</guid>
<pubDate>Wed, 17 Sep 2003 03:53:35 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7987383</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : that is way worse than what i am getting, i will post a 24 hour graph tonight when i get home... :) cheers...<br><i>[text was edited by author 2003-09-17 02:01:01]</i><br><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7987383?c=430370&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="16227 bytes" WIDTH=600 HEIGHT=463 SRC="/r0/download/430370.thumb600~016fe03dee867c1d3ed49335eef71151/pentarou.parodius.com.png/thumb.jpg" ALT="Click for full size"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7987383</guid>
<pubDate>Tue, 16 Sep 2003 23:30:18 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7987238</link>
<description><![CDATA[<A HREF="/useremail/u/873863"><b>GamingGirl</b></A> : This is what I saw when I got home tonight. I shut it down at 8pm as I didn't want my browsing to affect the results. It looks as if the packet loss really kicks in around the time everyone is booting up their systems in the morning and continues throughout the rest of the day. The ping spikes on my second hop are pretty much the only ones I see. My ping is fairly stable the rest of the way.<br><br>I will email you my information tonight Kat. =)<div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7987238?c=430305&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="134117 bytes" WIDTH=600 HEIGHT=520 SRC="/r0/download/430305.thumb600~a6d12baf2d607fa65656898336ff1358/091603.JPG/thumb.jpg" ALT="Click for full size"></A><br>9/16/03</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7987238</guid>
<pubDate>Tue, 16 Sep 2003 23:17:22 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7986308</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : the PDX pop is no longer having the packet loss issues i was seeing over the past week. Not sure if this was corrected with the last two outages that happened this month...<br><br>Carl you speak with fluid grace, but remember she is the PR person for the company on these forums, and i beleive that is the reason why she is the only person posting here. As for not releasing exactly what the issue is, I can understand that as well, as the company i work for does the exact same thing. most of the time the EU/End User, you and me, do not get all the information we want. yes we are paying for a service and yes we should get answers to our questions, but you more than anyone from reading your posts, should know that information of this type is not always available to able to be released due to NDA/Contracts and the what not...<br><br>/END<br><small>--<br>I post for myself, from myself. Statements made do not necessarily reflect the views of my employer, Charter Communications, or any of its subsidiaries.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7986308</guid>
<pubDate>Tue, 16 Sep 2003 21:43:38 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7984397</link>
<description><![CDATA[<A HREF="/useremail/u/459309"><b>Bondman</b></A> : Kat:<br>   The service through the Detroit NAP is very poor.  If it is going to take months to get this matter resolved how about some credit on our accounts.<br><br>Below is the ping results I just took moments ago. <br><br>Ping statistics for 64.81.159.2:<br>    Packets: Sent = 53, Received = 53, Lost = 0 (0% loss),<br>Approximate round trip times in milli-seconds:<br>    Minimum = 25ms, Maximum = 64ms, Average = 39ms<br><br>At times I do get Packet loss.  I used to get regularly pings of 16ms.  I could not ping my server from a Charter School that I was at today.  I have one of the old ADSL on a separate line that I had when I switched over from Flashcom.  I am very leery of changing to line share to save $10 when I am not getting the service I am paying for now and then get stuck on a new year contract.  If one does switch do they get a new modem and the phone filters?  <br><i>[text was edited by author 2003-09-16 18:59:22]</i><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7984397</guid>
<pubDate>Tue, 16 Sep 2003 18:47:56 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7983680</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : Sorry for the duplicate post.  I've asked to have one removed...<br><br>Carl F.<br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7983680</guid>
<pubDate>Tue, 16 Sep 2003 17:26:24 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7983599</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : Hi Kat -<br><br>I label my inferences as such, to make it clear that I'm<br>guessing and that I know I'm guessing.  I'm sure some of<br>my guesses are off the mark to some extent or another.<br>I'm also sure that some of my guesses are fairly close<br>to the mark.  If I had anything close to adequately<br>complete information, I wouldn't have to guess!  :^)<br><br>What follows, however, are not inferences, they're <br>behavioral observations.<br><br>1.  You poke your head up from time to time to tell us<br>    what the problem is definitely not.  So far since<br>    this issue arose in the last month, you've never <br>    spoken-up to tell us anything definite and   <br>    comprehensive about what the problem is.  (Blaster<br>    was a stressor, not a root cause.)<br><br>2.  You're being very clear on what seem like relevant<br>    facts: No upgrades to the SFO POP, no bandwidth caps,<br>    period!  I believe these things are true. Period!  :^)<br>    But they are unresponsive factoids.  They state some <br>    tidbit that dramatically narrows the intent of what<br>    someone wrote, and then responds to that narrowed<br>    intent.  I'm not a networking expert, so if I use<br>    a phrase like "bandwidth capping" to describe<br>    symptoms I've laid out in detail, I expect you to tell<br>    me that my symptoms are more consistent with what<br>    folks call "traffic throttling" (as Jester did), and<br>    then go on to address the broader concern.  Similarly,<br>    I didn't say that the upgrade possibly gone bad was<br>    on the SFO POP, and yet you respond narrowly to SFO,<br>    when I--and your CEO--are both talking about an<br>    infrastructure upgrade throughout SpeakEasy.  You<br>    use the rhetoric and cadences of a straight-talker,<br>    but I'm finding that understanding you and others from <br>    SpeakEasy depends on what the meaning of 'is' is,<br>    and how that narrows and misdirects my attention.<br><br>3.  When you offer a "debunking" factoid, you write with<br>    emphasis and a slight edge of self-righteousness,<br>    like a beleaguered person trying hard to be responsive.  <br>    However, having seen other posts from you that have been<br>    substantively responsive in abundant detail, without<br>    all the emphasis, you've evidenced that you're very<br>    smart and articulate, and know the difference between<br>    responsiveness and unresponsiveness.  I infer that you<br>    know that you're not currently offering us direct<br>    responses, whatever emphatic edge you put on the <br>    factoids you offer.  Emphasis is what you're using to <br>    backfill for whatever hard facts you're not sharing <br>    (and perhaps are not being shared with you).<br><br>4.  You've offered several of us escalation, which seems<br>    like very proactive, can-do problem solving.  But there<br>    has been no follow-up from whomever you might have<br>    escalated to.  The best I can say is that you are<br>    a proactive element in a largely inactive support<br>    organization.<br><br>5.  If you respond to nothing else, please respond to this.<br>    It's been almost three weeks since I opened my first<br>    trouble ticket.<br><br>WHO IS THE SINGLE POINT OF OWNERSHIP FOR MY PROBLEM, OR, WHY, AFTER SO MUCH TIME, DON'T I HAVE ONE WHO I CAN CONTACT DIRECTLY AND TROUBLE-SHOOT WITH CONJOINTLY?<br><br>    You're giving off all of the emotional signals of<br>    owning our problems, Kat, but in actual substance<br>    you don't fully own any of our problems, and I can't<br>    see that anyone does.  You guys aren't hotwired to<br>    each other like the Borg, so I can't expect nearly<br>    as consistent an outcome, knowing that my problem is<br>    somewhere in the SpeakEasy Collective.  ;^)  Talk to me<br>    about my single point of ownership, Kat, and how I<br>    arrange to work directly and collaboratively with her<br>    or him. <br><br>Finally, Kat, please don't get me wrong.  I think you're<br>doing a great job for SpeakEasy.  If I had a high-tech<br>company with a substantial online presence and customer<br>contact, I'd hire you in a heartbeat.  You're bright,<br>articulate, good-humored, and quickly connect well with<br>distressed customers.  You should definitely be on<br>SpeakEasy's must-retain short list.<br><br>All I ask is that you don't treat me/us like we're too<br>naive to know that doing a great job for SpeakEasy is not<br>always the same as solving our problems.  Sometimes the<br>body of facts is going to outrun your ability to spin<br>them.  At that point, it's time to go back to your bosses<br>(as you may well be doing) and insist on developing and<br>deploying Plan B.  I'm at the point where I'd like to see<br>Plan B in evidence.<br><br>The problem, I'm guessing, will be getting the people you<br>work for to embrace Plan B, or even that they need one.<br>I'm particularly under-whelmed at the agility of your <br>management team under crisis.  Most every response I've <br>received has been either an unfulfilled promise, or else<br>something that would have been timely and forthcoming two <br>to three days earlier, instead of begrudgingly, belatedly<br>acknowledging to me what I'd already figured out for myself.<br><br>Best regards,<br><br>Carl F.<br>San Francisco<br><br><br><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7983599</guid>
<pubDate>Tue, 16 Sep 2003 17:15:05 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7983562</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : Hi Kat -<br><br>I label my inferences as such, to make it clear that I'm<br>guessing and that I know I'm guessing.  I'm sure some of<br>my guesses are off the mark to some extent or another.<br>I'm also sure that some of my guesses are fairly close<br>to the mark.  If I had anything close to adequately<br>complete information, I wouldn't have to guess!  :^)<br><br>What follows, however, are not inferences, they're <br>behavioral observations.<br><br>1.  You poke your head up from time to time to tell us<br>    what the problem is definitely not.  So far since<br>    this issue arose in the last month, you've never <br>    spoken-up to tell us anything definite and   <br>    comprehensive about what the problem is.  (Blaster<br>    was a stressor, not a root cause.)<br><br>2.  You're being very clear on what seem like relevant<br>    facts: No upgrades to the SFO POP, no bandwidth caps,<br>    period!  I believe these things are true. Period!  :^)<br>    But they are unresponsive factoids.  They state some <br>    tidbit that dramatically narrows the intent of what<br>    someone wrote, and then responds to that narrowed<br>    intent.  I'm not a networking expert, so if I use<br>    a phrase like "bandwidth capping" to describe<br>    symptoms I've laid out in detail, I expect you to tell<br>    me that my symptoms are more consistent with what<br>    folks call "traffic throttling" (as Jester did), and<br>    then go on to address the broader concern.  Similarly,<br>    I didn't say that the upgrade possibly gone bad was<br>    on the SFO POP, and yet you respond narrowly to SFO,<br>    when I--and your CEO--are both talking about an<br>    infrastructure upgrade throughout SpeakEasy.  You<br>    use the rhetoric and cadences of a straight-talker,<br>    but I'm finding that understanding you and others from <br>    SpeakEasy depends on what the meaning of 'is' is,<br>    and how that narrows and misdirects my attention.<br><br>3.  When you offer a "debunking" factoid, you write with<br>    emphasis and a slight edge of self-righteousness,<br>    like a beleaguered person trying hard to be responsive.  <br>    However, having seen other posts from you that have been<br>    substantively responsive in abundant detail, without<br>    all the emphasis, you've evidenced that you're very<br>    smart and articulate, and know the difference between<br>    responsiveness and unresponsiveness.  I infer that you<br>    know that you're not currently offering us direct<br>    responses, whatever emphatic edge you put on the <br>    factoids you offer.  Emphasis is what you're using to <br>    backfill for whatever hard facts you're not sharing <br>    (and perhaps are not being shared with you).<br><br>4.  You've offered several of us escalation, which seems<br>    like very proactive, can-do problem solving.  But there<br>    has been no follow-up from whomever you might have<br>    escalated to.  The best I can say is that you are<br>    a proactive element in a largely inactive support<br>    organization.<br><br>5.  If you respond to nothing else, please respond to this.<br>    It's been almost three weeks since I opened my first<br>    trouble ticket.<br><br>WHO IS THE SINGLE POINT OF OWNERSHIP FOR MY PROBLEM, OR, WHY, AFTER SO MUCH TIME, DON'T I HAVE ONE WHO I CAN CONTACT DIRECTLY AND TROUBLE-SHOOT WITH CONJOINTLY?<br>You're giving off all of the emotional<br>    signals of owning our problems, Kat, but in substance<br>    you don't fully own any of our problems, and I can't<br>    see that anyone does.  You guys aren't hotwired to<br>    each other like the Borg, so I can't expect nearly<br>    as consistent an outcome, knowing that my problem is<br>    somewhere in the SpeakEasy Collective.  ;^)  Talk to me<br>    about my single point of ownership, Kat, and how I<br>    arrange to work directly and collaboratively with her<br>    or him. <br><br>Finally, Kat, please don't get me wrong.  I think you're<br>doing a great job for SpeakEasy.  If I had a high-tech<br>company with a substantial online presence and customer<br>contact, I'd hire you in a heartbeat.  You're bright,<br>articulate, good-humored, and quickly connect well with<br>distressed customers.  You should definitely be on<br>SpeakEasy's must-retain short list.<br><br>All I ask is that you don't treat me/us like we're too<br>naive to know that doing a great job for SpeakEasy is not<br>always the same as solving our problems.  Sometimes the<br>body of facts is going to outrun your ability to spin<br>them.  At that point, it's time to go back to your bosses<br>(as you may well be doing) and insist on developing and<br>deploying Plan B.  I'm at the point where I'd like to see<br>Plan B in evidence.<br><br>The problem, I'm guessing, will be getting the people you<br>work for to embrace Plan B, or even that they need one.<br>I'm particularly under-whelmed at the agility of your <br>management team under crisis.  Most every response I've <br>received has been either an unfulfilled promise, or else<br>something that would have been timely and forthcoming two <br>to three days earlier, instead of begrudgingly, belatedly<br>acknowledging to me what I'd already figured out for myself.<br><br>Best regards,<br><br>Carl F.<br>San Francisco<br><br><br><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7983562</guid>
<pubDate>Tue, 16 Sep 2003 17:12:10 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7983452</link>
<description><![CDATA[<A HREF="/useremail/u/169031"><b>falkclan</b></A> : WOW<br>I had been forgetting to check into these forums :(<br><br>I'm glad I did, but last night I FINALLY put in a ticket to speakeasy<br><br>my normal ping to chi.speakeasy.net (2nd hop) from here in Kansas City was 18ms<br><br>now I get 18ms to the gateway hop (x.x.x.1) and like 50ms to chi.speakeasy.net<br><br>seems it's widespread, hoping for a fix<br>I emailed you Kat, with my specific ticket<br>thanks<br><small>--<br>Alan Falk</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7983452</guid>
<pubDate>Tue, 16 Sep 2003 16:55:59 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7982300</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : Definitely - and we're still working on the issue as reported in NYC, CHI and LAX.  If possible, can you provide me with your account name via email?<br><br>Thanks,<br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7982300</guid>
<pubDate>Tue, 16 Sep 2003 14:27:48 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7982065</link>
<description><![CDATA[<A HREF="/useremail/u/873863"><b>GamingGirl</b></A> : I do appreciate your updates Kat. However, my problem is occurring on the LAX POP and despite my many attempts, not one person has addressed my concerns. I have updated my service ticket numerous times, I've sent email to a first level tech with his assurance that he would pass it to the AS tech assigned to my ticket. It has been over a week and the AS tech has not even bothered to call me back. When I call in to speak with him, he is always on another call. Covad has closed my ticket. Speakeasy has not provided me any reassurance that my problem is even valid. All I want is a usable connection and if that is not possible, I at least want an explanation about what you (as in Speakeasy) are doing to correct the problem. Telling me to hang in there while I am still being charged full price for a less than fully working connection is unsuitable, especially when these updates aren't even pertaining to me. I'm sure you could understand my frustration.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7982065</guid>
<pubDate>Tue, 16 Sep 2003 13:55:59 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7981764</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : Our POP upgrades will begin with Seattle - we have not installed new hardware in our SFO POP.  As I posted on Friday, we will be transitioning a large portion of customers over to a new circuit and router tonight to alleviate the max on packets per second that we're seeing on one of our SFO routers.<br><br>Basically, anyone here can infer, imply or extrapolate to their heart's content regarding the cause of this or any other issue.  That's pretty much one of the reasons that this forum is here - for open discussion of questions, concerns and experiences.  But I have always provided straight information in this forum over the past two years and will continue to do so.  Whether or not you elect to accept that information as fact is a personal decision. <br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7981764</guid>
<pubDate>Tue, 16 Sep 2003 13:17:09 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7980245</link>
<description><![CDATA[<A HREF="/useremail/u/853040"><b>Chicago_DSL6</b></A> : If this doesn't get the wheels in motion...<br><br>Anyone experiencing these issues and can not seem to get any sort of resoltuion after a reasonable amount of time, visit &raquo;<A HREF="http://www.secfraud.com/" >www.secfraud.com/</A> and email Marc Godino with your issues. He worked on a lawsuit against Earthlink in California and won.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7980245</guid>
<pubDate>Tue, 16 Sep 2003 09:21:00 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7971996</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : Here's a link to a different kind of data, and more<br>discussion, in SpeakEasy's own forums.<br><br>&raquo;<A HREF="http://forums.speakeasy.net/6/ubb.x?a=tpc&s=6516042&f=2686062&m=215606643&r=921608163#921608163" >forums.speakeasy.net/6/ubb.x?a=t&middot;&middot;&middot;1608163</A><br><br>My take is that it's neither the loss of average bandwidth <br>nor the intermittent packet loss that's killing our service,<br>but the VARIABILITY, the burstiness and the stalls that<br>are so long that packet recovery schemes built on top<br>of UDP (such as RealPlayer's fairly robust method)<br>cannot possibly recover lost packets on time.<br><br>I agree that SpeakEasy is buying time at this point.  I<br>have no access to information, and yet I am beginning to<br>feel as though I am characterizing the problem more <br>quickly than they are.  Of course, this is ridiculous.<br>SpeakEasy has not provided such great service over the<br>years, and grown so impressively, with a bunch of idiots<br>on their staff.  They are very bright people who have<br>access to much more information and who have much more<br>experience in interpreting their information.  To think<br>that I'm out in front of them characterizing their<br>problem is silly.<br><br>I infer that SpeakEasy knows much more than they are<br>choosing to share at this point.  The amount of <br>misinformation and scripted misdirection of attention from <br>a technical service department that used to be consistently<br>great is a strong indication that SpeakEasy is buying<br>time.  Why keep running phy level tests with Covad, when<br>the problem is time-of-day sensitive?  Is the concern that<br>after the sun comes-up and the line warms-up, that its<br>capacity drops precipitously?  ;^)  If I were Covad, I'd be<br>getting pretty annoyed at the amount of my tech support<br>resource being squandered by SpeakEasy just now.<br><br>SpeakEasy must be a much less fun place to work these days.<br>A crew that used to enjoy straightforward and direct<br>relations with customers now has to play poker for a living.<br>I certainly don't envy Kat Oak her job right now.  What<br>a tough position to be in!<br><br>There's a memo from their CEO announcing a major <br>upgrade to Juniper equipment on their forum.  Perhaps<br>the upgrade is not going well.  Perhaps they are trying<br>out new traffic management policies with the new<br>equipment, and our midday packet loss is an unanticipated<br>side-effect.  Perhaps SpeakEasy is testing the threshold<br>of pain in our segment of their market, to see how much<br>stability of traffic they can divert to big ticket<br>enterprise customers.  To the extent SpeakEasy has <br>enterprise customers in the $10,000+ per month range, our<br>complaints are unlikely to be handled with the same<br>priority.<br><br>But again, this could just be an upgrade gone really bad.  <br>After all, if SpeakEasy is not a big ticket customer for <br>Juniper, Juniper might have cocked-up the installation, <br>and is now tap-dancing for SpeakEasy the way that SpeakEasy<br>is tap-dancing for us.<br><br>My willingness to stick with SpeakEasy depends upon (1)<br>quick resolution of problems and (2) honest characterization<br>of problems when quick resolution is not possible.  That<br>honest characterization acknowledges, in our business<br>relationship, that we are both incurring damage.  When<br>problems are not forthrightly acknowledged, then SpeakEasy<br>makes the relationship all about their bottom line and<br>their saving face.<br><br>Please, SpeakEasy, get your network architects into this<br>discussion, and have them tell us what they know, and<br>how SpeakEasy plans to make all of us whole.<br><br>Cheers,<br><br>Carl F.<br>San Francisco]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7971996</guid>
<pubDate>Mon, 15 Sep 2003 12:29:37 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7971814</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Latest update.  From about 15:45 yesterday afternoon until 09:03 this morning.<br><br>Large square-wave ("ramping") effect you see at destination between 06:00 and 09:00 this morning caused by my co-lo provider doing some cabling maintenance.<br><br>P.S. -- The "packet stalling" problem I mention every so often was in full effect last night, particularly between 22:15 and 23:15.  Graph should prove that beyond a doubt.<br><SMALL>--<br>Making life hard for others since 1977.</SMALL><br><i>[text was edited by author 2003-09-15 12:08:47]</i><br><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7971814?c=429129&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="22735 bytes" WIDTH=600 HEIGHT=452 SRC="/r0/download/429129.thumb600~a7bd8a0f9b004602dd5e6723868f20ac/se_broke_5.png/thumb.jpg" ALT="Click for full size"></A><br>SFO 09/14 - 09/15</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7971814</guid>
<pubDate>Mon, 15 Sep 2003 12:05:40 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7971569</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : wow, thats insane gaminggirl...<br><br>mine shows loss only on my 2nd hop, which is a speakeasy router...<br><br>other than that, no loss...<br><br>i have two routes going right now with ping plotter, only another 12-15 hours and it wll be all done...<br><small>--<br>I post for myself, from myself. Statements made do not necessarily reflect the views of my employer, Charter Communications, or any of its subsidiaries.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7971569</guid>
<pubDate>Mon, 15 Sep 2003 11:24:28 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7969719</link>
<description><![CDATA[<A HREF="/useremail/u/873863"><b>GamingGirl</b></A> : Here is my ping plotter for one hour right before I called in for tech support (had to follow up on my support ticket ya know). I told the tech on the line that I wanted to send the .jpg to my advanced support technician (he was on the phone with Covad at the time...hmmm) so I ended up emailing it to the first level tech in the hopes that he would pass it on. He promised me that the AS tech assigned to my ticket would call me back... he never did =(. I have a feeling I'll get a call in the middle of the day tomorrow when I'm at work (isn't that how it always is?)... Anyhow, this ping plotter thing is fun =). I think I'll let it run tonight while I sleep and tomorrow while I work just to see how it does.<div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7969719?c=429000&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="177235 bytes" WIDTH=600 HEIGHT=528 SRC="/r0/download/429000.thumb600~e03978c8954616104fe28e70bfd71adc/PingPlotter2.JPG/thumb.jpg" ALT="Click for full size"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7969719</guid>
<pubDate>Mon, 15 Sep 2003 01:44:43 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7961493</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : Tracing route to vnsc-pri.sys.gtei.net [4.2.2.1]<br>over a maximum of 30 hops:<br><br>  1    20 ms    19 ms    19 ms  gate.tailie.net [66.93.174.1]<br>  2     *       19 ms    20 ms  ge0-0-0.brd-1-sea.speakeasy.net [206.191.168.200<br>]<br>  3    20 ms    19 ms    19 ms  border26s.g3-2.speakeasy-14.sea.pnap.net [206.19<br>1.168.220]<br>  4    20 ms    19 ms    18 ms  core4.ge0-0-0-bbnet1.sea.pnap.net [206.253.192.1<br>44]<br>  5    18 ms    19 ms    18 ms  p6-0.sttlwa1-cr1.bbnplanet.net [4.25.88.17]<br>  6    18 ms    21 ms    22 ms  so-2-0-0.sttlwa1-hcr1.bbnplanet.net [4.24.10.238<br>]<br>  7    20 ms    20 ms    21 ms  p3-0.sttlwa2-br1.bbnplanet.net [4.24.11.201]<br>  8    20 ms    20 ms    19 ms  p1-0.sttlwa2-cr1.bbnplanet.net [4.24.11.194]<br>  9    20 ms    18 ms    18 ms  vnsc-pri.sys.gtei.net [4.2.2.1]<br><br>Trace complete.<br><br>there i did that tracert, gonna start pingplotter and see where it takes me for the next 48 hours... :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7961493</guid>
<pubDate>Sun, 14 Sep 2003 02:38:13 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7961286</link>
<description><![CDATA[<A HREF="/useremail/u/873863"><b>GamingGirl</b></A> : koitsu, you are very informative =). I appreciate that... you're helping me understand a little better about things that Speakeasy can't or won't take the time to explain to me. Thank you =).<br><br>I downloaded the ping plotter program a few nights ago so last night I let it run while I slept... attached are the results. I guess I'm not seeing the dropped packets as badly as you are but nonetheless I am still seeing poor performance. <br><br>Both Covad and Speakeasy refuse to admit that there is any kind of problem or change that could possibly have affected my service (go figure *sigh*) but if this remains to be the norm over the next week or two, I'm just going to wave goodbye, pay the early termination fee and find a more suitable provider. <br><br>It's just a shame that they must think that I have nothing better to do than sit on hold, wait for a tech, explain my problem and hope for a resolution. One thing I have learned through working in customer service is that you don't hear from the customer when things are going good, you only hear from them when things are going bad. To be told that there is nothing wrong is saddening at the least =(. <br><br>I truly hope that you all find the resolution you are looking for because I'm not patient enough (nor willing to pay the incredible fees each month) to sit around praying that things will return to normal. The least they could do is say "ma'am, I am sorry that you aren't happy with our service, we will do everything we can to make things right"... instead I hear "ma'am, we don't even want to hear about what's affecting you unless you can show proof since we can't seem to reproduce the problem with our 'tools'". In fact, I don't even hear that unless I call in since Advanced Support doesn't seem willing to pick up the phone and follow up. =(<br><br>I don't get paid by Speakeasy to research and find out what is going on with my line, rather I pay them to do that for me and I'm just not seeing enough from their side to warrant my payment. I am truly disappointed.<div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7961286?c=428290&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="122281 bytes" WIDTH=600 HEIGHT=505 SRC="/r0/download/428290.thumb600~9145e9971c6b5470aa0be1db10c77f76/PingPlotter.JPG/thumb.jpg" ALT="Click for full size"></A><br>LAX to SFO</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7961286</guid>
<pubDate>Sun, 14 Sep 2003 01:46:35 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7960815</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Following in the footsteps of the thread subject, included above is the latest Ping Plotter results over the past 48 hours (and then some).<br><br>I'm somewhat bothered by the fact that today -- Saturday -- shows no ramping usage spike from 09:00 until midnight (or, well, technically 21:33).<br><br>Just posting this for Kat and anyone else who's interested in how SFO is doing.  That huge packet loss problem around 23:30 to midnight last night, I'm hoping, was caused either by Verio or possibly changes with InterNAP or SE.<br><br>That's all for now!<br><small>--<br>Making life hard for others since 1977.</small><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7960815?c=428253&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="23030 bytes" WIDTH=600 HEIGHT=465 SRC="/r0/download/428253.thumb600~64db77c77d39a0532c325df9ec4cab44/se_latest.png/thumb.jpg" ALT="Click for full size"></A><br>SE, 09/12 to 09/13</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7960815</guid>
<pubDate>Sun, 14 Sep 2003 00:33:45 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7958271</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : yeah, i noticed that as well... i downloaded the free pingplotter yesterday and the tracert completed... :(<br><br>i will test some other stuff once i get home tonight...<br><br>here is something i did from work, ping test almost all day, from 1:30pm to 8:53pm...<br><br>Ping statistics for 66.93.174.127:<br>    Packets: Sent = 26297, Received = 26290, Lost = 7 (0% loss),<br>Approximate round trip times in milli-seconds:<br>    Minimum = 15ms, Maximum =  547ms, Average =  18ms<br><br><SMALL>--<br>I post for myself, from myself. Statements made do not necessarily reflect the views of my employer, Charter Communications, or any of its subsidiaries.</SMALL><br><i>[text was edited by author 2003-09-13 23:53:26]</i><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7958271</guid>
<pubDate>Sat, 13 Sep 2003 19:03:14 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7958082</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : So to sum everything up, literally InterNAP is just a customer who happens to have service with multiple backbone providers (Global Crossing, Verio, Level 3, Alter, and a few other who's names are slipping my mind since I just woke up), then proceed to resell portions of their own POP, with their mysterious BGP setup deployed, to customers (like SE) for network connectivity.<br><br>Likewise, the reason for their entertaining merry-go-round routing procedures is a purely financial one due to the costs of aggregate bandwidth total per peering point (hence balancing out the traffic between all providers rather than shoving it all through one which happens to have the lowest hop count and more reliable link (at that time)).<br><br>What a bummer.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7958082</guid>
<pubDate>Sat, 13 Sep 2003 18:40:02 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7958019</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : The examples you show above make it all the way to a Sprint peering point in Chicago (for BBR) and a peering point with Level 3 in (probably) their Santa Clara POP (for Yahoo).<br><br>I can't provide you traceroutes for comparison to either www.yahoo.com or www.broadbandreports.com because the route packets go from my co-lo to either of those sites are completely different.  (Heck, my co-lo is 6 hops from www.yahoo.com, go figure).<br><br>Try tracerouting to a different destination.  For example, 4.2.2.1 (which is a public nameserver hosted by GTEI):<br><br>Tracing route to vnsc-pri.sys.gtei.net [4.2.2.1]<br>over a maximum of 30 hops:<br><br>  1    1 ms    1 ms    1 ms  192.168.0.1<br>  2    11 ms    11 ms    11 ms  dsl081-051-001.sfo1.dsl.speakeasy.net [64.81.51.1]<br>  3    11 ms    12 ms    12 ms  border5.g3-4.speakeasy-29.sfo.pnap.net [63.251.53.219]<br>  4    12 ms    11 ms    11 ms  core1.ge0-0-bbnet1.sfo.pnap.net [63.251.63.1]<br>  5    12 ms    12 ms    12 ms  sl-gw13-sj-0-2-155M.sprintlink.net [160.81.100.1]<br>  6    13 ms    12 ms    11 ms  sl-bb21-sj-6-0.sprintlink.net [144.232.3.173]<br>  7    13 ms    13 ms    12 ms  sl-st20-sj-13-0.sprintlink.net [144.232.9.58]<br>  8    15 ms    14 ms    13 ms  interconnect-eng.SanJose1.Level3.net [209.245.146.245]<br>  9    13 ms    14 ms    14 ms  so-5-0-0.gar1.SanJose1.level3.net [209.244.3.137]<br> 10    15 ms    15 ms    13 ms  so-7-0-0.mp1.SanJose1.Level3.net [64.159.1.73]<br> 11    78 ms    79 ms    79 ms  so-0-2-0.bbr1.Atlanta1.level3.net [209.247.9.101]<br> 12    78 ms    78 ms    79 ms  pos8-0.hsa1.Atlanta1.Level3.net [209.247.9.166]<br> 13    79 ms    81 ms    78 ms  vlan521.public-msf1.Atlanta2.Level3.net [67.72.92.18]<br> 14    78 ms    81 ms    79 ms  vnsc-pri.sys.gtei.net [4.2.2.1]<br><br>One thing to note: it looks to me that Ping Plotter and Windows traceroute may be using different protocols (possibly ICMP vs. UDP) for their tests.  I cannot traceroute to my co-lo using Windows tracert (dies at hop #5), while using Ping Plotter from the same box works fine. Hop #5, in this case, happens to be so-3-0-0.ar4.SFO1.gblx.net.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7958019</guid>
<pubDate>Sat, 13 Sep 2003 18:30:52 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7958011</link>
<description><![CDATA[<A HREF="/useremail/u/168864"><b>sporkme</b></A> :  <BLOCKQUOTE><SMALL>said by  koitsu <A HREF="/useremail/u/659143"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>InterNAP is who Speakeasy peers with.  InterNAP peers with all sorts-of different providers; it's synonymous with the PAIX in Palo Alto (i.e. a central point for many backbone providers to connect to one another, hence making the Internet work).<br><HR></BLOCKQUOTE><br><br>It's not really synonymous.  InterNAP buys *transit* from mutliple providers, likely at some fixed price point if they guarantee "X" number of megabits/sec average.  At a peering point like PAIX, providers go there to exhange *peering*, which is *not* the same as paying for transit.  They will agree on a pipe of some size, who will pay what portion of the interconnect, and agree that this is of mutual benefit to them as ISP X's customer's can now directly reach ISP Y's customers without either side paying each other for transit.  These days it's a bit more complicated than that, but that's the theory at least.<br><br>InterNAP is simply a paying customer of a number of backbones.  They have no network interconnecting their PoPs, each one is an "island".  The original plan was to sell "premium connectivity", but ever since they've had financial difficulties, it's become a bit different.  You now see more and more traffic going out the cheapest providers.  One day we'll see Cogent in the mix. :)<br><br> <BLOCKQUOTE><SMALL>said by  koitsu <A HREF="/useremail/u/659143"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR><br>InterNAP has some seriously magic BGP voodoo going on -- they drop/swap routes practically on an hourly basis.  Even when the interface you're going through is absolutely 100% clean (e.g. prior to all of this packet loss crap), they will _still_ drop the route and switch you from, for sake of example, GBLX to ALTER for <B>absolutely no reason</B>.  That's why I say it's "magic BGP voodoo."  <B>This is NOT how BGP is normally supposed to be used</B>, and it looks to me like InterNAP simply uses some excessively anal settings, or simply plays spin-a-roo with their routes (I've heard of peering providers doing this as well, but it's not very common). <HR></BLOCKQUOTE><br><br>This is certainly on purpose, and it's so that they meet their contractual agreements with each provider without going over/under what they've agreed to buy from each provider.  I would not be at all surprised to find a RouteScience box at each PoP twiddling all these paths for them.  RouteScience, &raquo;<A HREF="http://www.routescience.com/" >www.routescience.com/</A>, is a really nifty thing, but it's just a tool.  It's generally used to *improve* performance, but it also has many options that let you say "we don't want to average more than 10Mb/s this month, we don't want to average more than 40Mb/x this month to Level3, but we'll go up to 100Mb/s to Verio, and Cogent is unlimited".<br><br>Hopefully one day SE will get more neteng people on board and think about simply multihoming themselves to 5 or 6 providers at each PoP and managing this themselves.  It requires more time and talent, but in today's fluctuating bandwidth market, it makes sense to add and drop providers on a regular basis.  If they are in good facilities with low x-connect charges, it's a win-win.<br><small>--<br><A HREF="http://www.speakeasy.org/~spork">just a minute</A></small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7958011</guid>
<pubDate>Sat, 13 Sep 2003 18:29:53 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7957703</link>
<description><![CDATA[<A HREF="/useremail/u/816633"><b>wattjg</b></A> : They may be blocking UDP but not ICMP echo requests.  The only thing that's odd is that the Windows "tracert" uses ICMP.  Unix traceroutes commonly use UDP by default.  Both Windows and Unix "ping" use ICMP.<br><br>That's not consistent with your data, but I was able to "tracert" (Windows) to www.dslreports.com, but not "traceroute" (Unix/FreeBSD) to it.  I can "ping" it from both  machines.<br><br>Jim]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7957703</guid>
<pubDate>Sat, 13 Sep 2003 17:44:53 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7957665</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : well they used to complete :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7957665</guid>
<pubDate>Sat, 13 Sep 2003 17:40:25 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7957453</link>
<description><![CDATA[<A HREF="/useremail/u/459309"><b>Bondman</b></A> : Paul:<br>   I get timeouts on tracerts to WWW.BroadbandReports.com as well unfortunately but I am able to ping them.  I think Speakeasy needs to push for better service from their backbone providers.<br><br>tracert www.broadbandreports.com<br><br>Tracing route to broadbandreports.com [209.123.109.175]<br>over a maximum of 30 hops:<br><br>  1    1 ms    1 ms    1 ms  ml350.server-tech.local [10.1.1.1]<br>  2    17 ms    16 ms    16 ms  dsl093-002-001.det1.dsl.speakeasy.net [66.93.2.1<br>]<br>  3    30 ms    19 ms    32 ms  border5.ge3-2.speakeasy-28.chg.pnap.net [64.94.3<br>5.212]<br>  4    19 ms    19 ms    19 ms  core2.fe0-1-bbnet2.chg.pnap.net [64.94.32.66]<br>  5    19 ms    18 ms    20 ms  POS3-1.GW1.CHI13.ALTER.NET [65.207.239.21]<br>  6    20 ms    18 ms    18 ms  0.so-1-0-0.XL1.CHI13.ALTER.NET [152.63.69.178]<br>  7    21 ms    20 ms    20 ms  0.so-2-2-0.XL1.CHI2.ALTER.NET [152.63.70.102]<br>  8    19 ms    20 ms    19 ms  POS6-0.BR2.CHI2.ALTER.NET [152.63.67.241]<br>  9     *        *        *     Request timed out.<br> 10     *        *        *     Request timed out.<br> 11     *        *        *     Request timed out.<br> 12     *        *        *     Request timed out.<br> 13     *        *        *     Request timed out.<br> 14     *        *     <br><br>ping www.broadbandreports.com<br><br>Pinging broadbandreports.com [209.123.109.175] with 32 bytes of data:<br><br>Reply from 209.123.109.175: bytes=32 time=53ms TTL=53<br>Reply from 209.123.109.175: bytes=32 time=52ms TTL=53<br>Reply from 209.123.109.175: bytes=32 time=53ms TTL=53<br>Reply from 209.123.109.175: bytes=32 time=63ms TTL=53<br><br>Ping statistics for 209.123.109.175:<br>    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),<br>Approximate round trip times in milli-seconds:<br>    Minimum = 52ms, Maximum = 63ms, Average = 55ms<br><br><i>[text was edited by author 2003-09-13 17:28:49]</i><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7957453</guid>
<pubDate>Sat, 13 Sep 2003 17:09:35 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7957013</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : any idea why my tracerts no longer complete?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7957013</guid>
<pubDate>Sat, 13 Sep 2003 16:00:32 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7953668</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : InterNAP is who Speakeasy peers with.  InterNAP peers with all sorts-of different providers; it's synonymous with the PAIX in Palo Alto (i.e. a central point for many backbone providers to connect to one another, hence making the Internet work).<br><br>InterNAP is a double-edged sword, and I'm sure Kat can talk a bit about why this is as well.  It's fantastic -- when everything is working how it should be.  Otherwise it's an absolute nightmare to debunk, since they seem to change routes almost at the drop of a coin.<br><br>InterNAP has some seriously magic BGP voodoo going on -- they drop/swap routes practically on an hourly basis.  Even when the interface you're going through is absolutely 100% clean (e.g. prior to all of this packet loss crap), they will _still_ drop the route and switch you from, for sake of example, GBLX to ALTER for <B>absolutely no reason</B>.  That's why I say it's "magic BGP voodoo."  <B>This is NOT how BGP is normally supposed to be used</B>, and it looks to me like InterNAP simply uses some excessively anal settings, or simply plays spin-a-roo with their routes (I've heard of peering providers doing this as well, but it's not very common).<br><br>The rep. you spoke to was correct in his description of what's <I>supposed</I> to happen -- when there's a network outage or major anomaly (i.e. packet loss, CRC errors, line errors, or anything else that generally affects POS (Packet Over Sonet) links), BGP will automatically say "Link is screwed, dropping route automatically, moving to another peer."  In about 90% of the cases out there, this works great.  InterNAP simply deploys this along side a bunch of other stuff -- it's the other stuff which is causing your traceroutes to show different routes every hour, or sometimes as often as every 15 minutes.  Oh, BGP stands for Border Gateway Protocol, by the way -- it's just a monitoring protocol that allow routers to make automatic configuration changes based upon rulesets to determine if a network is functioning "up to par" or not.<br><br>The best way to understand all of this is to get the utility called Ping Plotter and let it run for a few hours again a website you commonly visit (use www.news.com if you need a default).  If you know how to use traceroute, then PP will make perfect sense to you -- except that it's a graphical representation of a continual traceroute.  One of the coolest features of PP is that it detects and logs route changes, so you can see exactly where, when, and why a route was changed.  The other thing it's useful for is showing actual graphs of packet loss and latency.  Try it out, you might like it -- for *IX I prefer mtr (matt's traceroute), while for Windows I prefer Ping Plotter.<br><br>Hope this helps.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7953668</guid>
<pubDate>Sat, 13 Sep 2003 06:37:10 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7953653</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Sadly, Verio here in SFO is absolute garbage (I can vouch for this, as I worked for them for 3 years here in the Bay); packet loss madness.  I'm presently seeing a consistent 5-6% loss from Verio.  It does not fluxuate.  It's good to know Verio's PDX POP is still standing (the head west coast network engineer lives there ;-) ).<br><br>The two best peering points through SFO InterNAP look to be Level3 and Alter.  At least for where I'm commonly going those look to be the best.<br><br>I'll cover the "random route" thing that GamingGirl asked in the next post.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7953653</guid>
<pubDate>Sat, 13 Sep 2003 06:27:19 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7953436</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : my stuff is getting routed sadly through level 3 and keeps dropping tons of packets with tracerts... it sucks...<br><br>AT&T is the carried for the PDX area... and they have problems big time... not sure why speakeasy chose to this provider as the backbone transport...<br><br>Verio/Sprintlink are nice... good ping times etc...<br><br>anywho... i dunno... i am sooo tired...<br><br>example...<br><br>traceroutes to both yahoo & here...<br><br>Tracing route to broadbandreports.com [209.123.109.175]<br>over a maximum of 30 hops:<br><br>  1    19 ms    19 ms    19 ms  gate.tailie.net [66.93.174.1]<br>  2    39 ms    44 ms     *     ge0-0-0.brd-1-sea.speakeasy.net [206.191.168.200<br>]<br>  3    17 ms    17 ms    18 ms  border26s.g3-2.speakeasy-14.sea.pnap.net [206.19<br>1.168.220]<br>  4    17 ms    17 ms    16 ms  core1.ge2-0-bbnet1.sea.pnap.net [206.253.192.129<br>]<br>  5    17 ms    17 ms    16 ms  sl-gw11-sea-1-0.sprintlink.net [144.228.95.45]<br>  6    16 ms    15 ms    15 ms  sl-bb21-sea-9-3.sprintlink.net [144.232.6.117]<br>  7    59 ms    59 ms    59 ms  sl-bb25-chi-2-0.sprintlink.net [144.232.20.157]<br><br>  8    59 ms    59 ms    59 ms  sl-bb21-chi-13-0.sprintlink.net [144.232.26.89]<br><br>  9    61 ms    61 ms    60 ms  sl-st20-chi-15-1.sprintlink.net [144.232.20.80]<br><br> 10     *        *        *     Request timed out.<br> 11     *        *        *     Request timed out.<br> 12     *        *        *     Request timed out.<br> 13     *        *        *     Request timed out.<br><br>Tracing route to yahoo.com [66.218.71.198]<br>over a maximum of 30 hops:<br><br>  1    20 ms    19 ms    19 ms  gate.tailie.net [66.93.174.1]<br>  2     *        *        *     Request timed out.<br>  3    19 ms    19 ms    19 ms  border26s.g3-2.speakeasy-14.sea.pnap.net [206.19<br>1.168.220]<br>  4    17 ms    18 ms    18 ms  core2.ge2-0-bbnet1.sea.pnap.net [206.253.192.130<br>]<br>  5    17 ms    17 ms    17 ms  12.124.173.37<br>  6    17 ms    16 ms    16 ms  gbr2-p60.st6wa.ip.att.net [12.123.44.118]<br>  7    18 ms    18 ms    18 ms  tbr1-p012601.st6wa.ip.att.net [12.122.12.161]<br>  8    15 ms    16 ms    15 ms  ggr1-p340.st6wa.ip.att.net [12.123.44.129]<br>  9    33 ms    33 ms    32 ms  att-gw.sea.level3.net [192.205.32.22]<br> 10    34 ms    34 ms    34 ms  ge-6-0-1.mp1.Seattle1.level3.net [209.247.9.45]<br><br> 11    34 ms    34 ms    33 ms  so-3-0-0.mp2.SanJose1.Level3.net [64.159.1.130]<br><br> 12    33 ms    34 ms    34 ms  gige10-2.ipcolo3.SanJose1.Level3.net [64.159.2.1<br>69]<br> 13    36 ms    35 ms    34 ms  unknown.Level3.net [64.152.69.30]<br> 14     *        *        *     Request timed out.<br> 15     *        *        *     Request timed out.<br> 16     *        *        *     Request timed out.<br> 17     *        *        *     Request timed out.<br><br>They never complete anymore... :( can ping the sites though<br><small>--<br>I post for myself, from myself. Statements made do not necessarily reflect the views of my employer, Charter Communications, or any of its subsidiaries.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7953436</guid>
<pubDate>Sat, 13 Sep 2003 03:47:02 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7953385</link>
<description><![CDATA[<A HREF="/useremail/u/873863"><b>GamingGirl</b></A> :  <BLOCKQUOTE><SMALL>said by  TrueAudio <A HREF="/useremail/u/590956"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>...and there seems to be allot of route changes going on. I haven't been keep much track of the packet loss, but I do notice it... <HR></BLOCKQUOTE><br><br>I've noticed a lot of routing changes as well. I asked the rep. that I spoke with earlier why I was seeing all these different routes to one of the websites I typically trace (out of curiosity of course =) ) and he told me that "sometimes when a router goes down the route will get changed but Speakeasy hasn't made any changes to the way things get routed". However, I am seeing a lot of sprintlink and att routes that I never saw before. I used to see mainly ALTER for my trips across the US. However, as I said in a previous post, I'm not technically inclined in the least so it could all still be the same but with a different name... what do I know =)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7953385</guid>
<pubDate>Sat, 13 Sep 2003 03:25:30 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7953362</link>
<description><![CDATA[<A HREF="/useremail/u/873863"><b>GamingGirl</b></A> : Ok, this is what I found in my service ticket area when I logged into MySpeakeasy...<br><br>2003-09-12 17:00:30    Backhaul installed<br>Statused TT.  ISP has reported Dropping Packets (Slow throughput, latency, packet loss).  Training Starts:  0 ( 69 )  Reprovisioned loop per ISP request.  Training Starts:  0 ( 70 ).  This circuit has had 1 previous trouble tickets for RMA.  TT will be placed into CPPV>  TT will auto close w/in 24 hrs.  <br>Not able to reproduce.  Trace routes<br>die at our redback, and could be<br>condition of latency between redback<br>and customer.  Please depro/repro<br>the port to see if this helps the<br>situation.  Thank you.<br>DSLAM Trunk Status:  OK  <br>Technology:  DMT8-2  <br>Card Status:  OK  <br>Port Status:  Up  <br>Actual Port Rates:  1536 kbps Downstream / 768 kbps Upstream  <br>Margin:  26.0 dB Downstream / 9.5 dB Upstream  <br> <br>2003-09-12 17:01:06    Backhaul installed<br>CLOSED-Pending Partner Verify  <br> <br>Unfortunately the reprovision didn't do anything =(. I see lots of latency at my second hop and dropped packets from that point on. What does it mean when they say "Trace routes<br>die at our redback, and could be condition of latency between redback and customer"? <br><br>I think I'm just out of luck =( Unfortunately, I still have six months on my contract so it doesn't look like I have many options at this point... too sad. =(]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7953362</guid>
<pubDate>Sat, 13 Sep 2003 03:18:44 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7952699</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : agreed, i am out of the PDX pop, so far no issues as your guys are talking about...<br><br>only the two major outages that lasted long than 4 hours, once was the who dang pop went down, then AT&T screwed up everything...<br><br>Did that to the company i work for Charter, numerous times... :(<br><br>I hate seeing posts like these anywhere especially for people who use the same service as me, or the company I work for...<br><br>Oh, did I mention that tracerts no longer work correctly???<br><br>Have the time every other hop times out now... hmm...<br><br>My fingers are crossed for resolution of the issue you are all having...<br><br>As for my just look at my thread, Transfer Nightmare (still is by the way, being ignored still :()<br><SMALL>--<br>I post for myself, from myself. Statements made do not necessarily reflect the views of my employer, Charter Communications, or any of its subsidiaries.</SMALL><br><i>[text was edited by author 2003-09-13 00:53:11]</i><br>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7952699</guid>
<pubDate>Sat, 13 Sep 2003 00:52:14 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7952186</link>
<description><![CDATA[<A HREF="/useremail/u/590956"><b>TrueAudio</b></A> : Nobody wants to upgrade there systems till its absolutely necessary. Those routers and servers are super expensive.<br>Its just gets to a point where customers know what there talking about and experiencing, and start calling the company on it, and then they are forced to take some kind of action. Since they do a great deal of advertising from DSL reports I would think it would be in there best interest to keep the customers that post here happy, and with service they are expecting to receive. <br><br>I ordered this service because of the ads on this website. I saw allot of people praising the service and that really turned me on. Im 3 or 4 days into this service, and im already experiencing complete loss of connection for about 15-20 seconds, then it pops back, and there seems to be allot of route changes going on. I haven't been keep much track of the packet loss, but I do notice it. <br><br>Well... I hope they are upgrading around here(SFO). Its seems like they bay area has allot of packet loss on some of the major ISP's. Tons of data flowing out of Cali & Seattle.. that's for sure.<br><br>I guess we wait and see. Good luck to those who are having problems.<br><small>--<br>&raquo;<A HREF="http://www.mtndewbuzz.com" >www.mtndewbuzz.com</A></small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7952186</guid>
<pubDate>Fri, 12 Sep 2003 23:43:48 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7950441</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : *sigh*  Shady technical support reps.  Thumbs down.<br><br>First off, what the rep. was referring to was the fact that UDP traffic by nature is lossy -- there is absolutely no guarantee that the packet will reach it's destination.  The protocol is basically a "send the packet and pray" medium.  TCP, on the other hand, guarantees that your packet makes it to it's destination due to handshaking (TCP SYN/ACK).  Most games use UDP for their actual transmission of movement, shots fired, blah blah blah, because of two reasons: 1) UDP is by far less intensive on a server (as far as processing goes), and 2) if some bloke running along happens to miss a delivery packet, big whoop, he'll send another one half a second later anyways.  Now you know why gamers who have slow or saturated net connections "jump around" a lot, and why latency plays a big role.<br><br>The issue I have with what the rep. told you is that the problem we're all experience has _NOTHING_ to do with the kind-of traffic that's being propagated -- TCP, UDP, ICMP.  It doesn't matter.  The results are the same no matter which protocol you use: the POPs are a mess.  The rep. shouldn't be giving you some schmooze about how they "can't do anything about UDP traffic."  I get stalls and lag via ssh to my co-lo, which is _entirely_ TCP-based, and I still don't see them bending over backwards about it (because the problem has NOTHING to do with protocols!  :-) ).<br><br>The fact that SE calls their "gamer package" a "package for gamers" is misleading.  All of the packages are the same, just with different speeds or different account options (i.e. shell accounts, 10 Email boxes, and so on).  There's absolutely no difference, DSL or network wise, between the SysAdmin package and the Gamer package.  It's just marketing schmooze.<br><br>Your latency problem will probably get solved when they deploy what Kat <A HREF="http://www.broadbandreports.com/forum/remark,7863751~root=speakeasy~mode=flat~start=40;iframe=1#7949223">said above in her most recent post</A>.  I can attest to seeing a _very_ marginal increase in stability since 9/9 (re: MSBlast terminating itself), but the problem (not to sound like a braggart) is definitely looking like oversaturation, which is what I claimed in the first place.  *shakes head*<br><br>Ah well.  We'll see how it goes.  I'm glad the Seattle folks are getting the upgrade first since their POP is absolutely horrid.  I just hope SFO and LAX are next.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7950441</guid>
<pubDate>Fri, 12 Sep 2003 20:18:27 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7950324</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : "my feelings are this se knows its got problems ok but if they can buy a lil time by having you do the ping ploter thing they will play that game with you as they did me till i called their bluff. just tell them you cannot reproduce the symptoms and document them because its udp connectionless service when i told them thats when things started going my way so give that a shot"<br><br>Hiya Catskinner... well, that didn't work for me. I called and spoke to the first person, told him what was going on and he proceeded to tell me that there is nothing they could do for UDP traffic...something about it not being able to be corrected en route or something. He told me that it was my game that was causing it (huh?!). He wanted me to believe that it was the netcode or something... two years of never experiencing packet loss and then all of a sudden the game socks me in the back? I don't think so =(.<br><br>Of course I began to ask him why there is no way it could have to do with the network if the packets still use the network to reach me. He decided to transfer me to advanced support (finally!). The advanced support guy said that he sent 100 packets to me and saw no packet loss. When I explained about my game and the UDP traffic he said "we can't even count what happens in your game"... Ok, my big problem with this is, I pay for the so called Gamer Package. Like duh, I use my connection for gaming. When my connection becomes useless to me for that purpose, of course I want things fixed. For them to tell me that the problems I am experiencing in game (and to a lesser extent outside of it) are not relevant and deserve no time for discussion is ludicrous. Why sell me a package geared for gaming (knowing that UDP traffic is what consists of gaming) if they refuse to support me when I am having a problem with the very marketing tool they sold me? That's like me buying shampoo, finding out there's dirt inside and being told "I'm sorry, it may be called shampoo but we didn't say it worked like it!" =( <br><br>I'm not normally someone who gets upset easily but I feel ignored and I'm just very frustrated. I'm sure that if all I did was surf the net I wouldn't have much to complain about, but then again I wouldn't be paying 100 bucks a month to do it... sigh =(.<br><br>He did say that he is going to have Covad reprovision my line to see if that helps my latency (a whole other issue) so who knows, maybe that will work. ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7950324</guid>
<pubDate>Fri, 12 Sep 2003 20:02:25 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7950195</link>
<description><![CDATA[<A HREF="/useremail/u/796415"><b>GeminiCub4U</b></A> : Kat can you please put me on the new router?  Im a new customer and am experiencing latency and packet loss.<br><small>--<br>Reality TV has taken over me.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7950195</guid>
<pubDate>Fri, 12 Sep 2003 19:49:28 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7949223</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : Status:<br><br>Although we've been aggressively pursuing customers that have been reported as infected with the MSBlaster worm or its variants, the packet loss that is occurring as a result of this has decreased only marginally.<br><br>The Blaster worm & its variants basically scan everything within its class B subnet relentlessly, and we've a couple of these shared with other organizations with whom we've also been in contact with in order to cut down the traffic we're seeing as a result of this worm.  <br><br>Packet loss is as a result of a maxing of the packets per second that can be processed by our routers.  We will be upgrading all of our equipment so in the future we are able to filter/block these kinds of attacks based on more individualized rule sets, instead of the global filters we'd need to put in place right now.<br><br>We did attempt a filter on port 135 about 3 weeks ago, but had to pull it due to complaints from Exchange and Windows Filesharing users.<br><br>All recorded complaints of packet loss and latency in the SFO area have been customers on one of our routers - we will be transitioning 40% of the customers off of this router and circuit and onto a new router and circuit to alleviate the issue in the short term.<br><br>In Seattle, we will begin our POP upgrade next week and will have all new equipment in place within the next few weeks.<br><br>We have just a handful of issues in a couple of our other POPs, and will continue to monitor those and work with customers infected with this worm in order to alleviate any load that we're seeing.<br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7949223</guid>
<pubDate>Fri, 12 Sep 2003 17:54:14 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7948659</link>
<description><![CDATA[<A HREF="/useremail/u/585933"><b>sh0V3L</b></A> : i finaly got them to aknowledge the fact the sfo pops are borked fubar and then some lol.i recieved an email stating a temp fix in the next few days then a permanent one in 2 weeks as they do some upgrades i realized se was violating the tos for sdsl premium routing as it states 2hops to backbone.for 2 months or whatever it is since they did the last duct tape and tie wire fix at sfo its been minimum 3 hops so i had them by the...... heh you get the picture lol so we will se if they do as said.<br><br> <BLOCKQUOTE><SMALL>said by GamingGirl:</SMALL><HR>I just got that ping plotter program and I'm wondering... what size packets should I use to accurately show the way my line reacts when playing online games (Unreal Tournament to be exact)? <HR></BLOCKQUOTE><br><br>hi gaming girl im an ut nut too well now ut2003 i ran ut servers for 3 yrs and now ut2003 for 1 yr or more.<br><br>i dont think the packet really matters, why? because ut is all udp as far as actual game play server to client. the ping is icmp and the initial handshake is tcp so the routers will handle udp different than the icmp ping.<br><br>my feelings are this se knows its got problems ok but if they can buy a lil time by having you do the ping ploter thing they will play that game with you as they did me till i called their bluff. just tell them you cannot reproduce the symptoms and document them because its udp connectionless service when i told them thats when things started going my way so give that a shot <br><br>frag ya l8r gg]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7948659</guid>
<pubDate>Fri, 12 Sep 2003 16:57:09 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7946250</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> : FYI....<br><br>I got a call last night from SE(yes they called me) to inform me that there would be a hardware upgrade/changeout taking place next Wednesday that should take care of my issues on the Seattle POP.  I will update....<br><br>Self]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7946250</guid>
<pubDate>Fri, 12 Sep 2003 12:19:27 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7943864</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : The default (56 bytes) probably isn't going to be good, but don't pick something absurdly large either (most routers will ignore large windowed ICMP packets).  Pick something like 1020 bytes, or maybe 516.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7943864</guid>
<pubDate>Fri, 12 Sep 2003 02:51:41 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7943566</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : I just got that ping plotter program and I'm wondering... what size packets should I use to accurately show the way my line reacts when playing online games (Unreal Tournament to be exact)?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7943566</guid>
<pubDate>Fri, 12 Sep 2003 01:35:32 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7934567</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : I'm not as technically savvy as most of you are but here are some traceroutes I did last night... I'm too tired to wait for them to complete tonight but this will show you that something wacky is going on as I've seen this consistantly for over a week now...<br><br>Tracing route to dslreports.com [209.123.109.175]<br>over a maximum of 30 hops:<br><br>1 11 ms 11 ms 11 ms dsl081-084-001.lax1.dsl.speakeasy.net [64.81.84.<br>1]<br>2 11 ms 13 ms 11 ms border12.fe4-0.speakeasy-32.lax.pnap.net [63.251<br>.223.91]<br>3 12 ms 13 ms 13 ms core1.ge2-0-bbnet1.lax.pnap.net [216.52.255.1]<br>4 14 ms 13 ms 13 ms sl-st20-la-10-0.sprintlink.net [144.232.154.205]<br><br>5 * * * Request timed out.<br>6 * * * Request timed out.<br>7 * * * Request timed out.<br>8 * * * Request timed out.<br>9 * * * Request timed out.<br>10 * * * Request timed out.<br>11 * * * Request timed out.<br>12 * * * Request timed out.<br>13 * * * Request timed out.<br>14 * * * Request timed out.<br>15 * * * Request timed out.<br><br>Trace complete.<br><br>Here's a trace to a website I visit based on the east coast...<br><br>Tracing route to www.iglnet.com [66.151.180.190]<br>over a maximum of 30 hops:<br><br>1 10 ms 11 ms 11 ms dsl081-084-001.lax1.dsl.speakeasy.net [64.81.84.<br>1]<br>2 * 11 ms 11 ms border12.fe4-0.speakeasy-32.lax.pnap.net [63.251<br>.223.91]<br>3 12 ms 15 ms 11 ms core1.ge2-0-bbnet1.lax.pnap.net [216.52.255.1]<br>4 10 ms 13 ms 11 ms gigabitethernet5-1-180.ipcolo2.LosAngeles1.Level<br>3.net [63.208.234.133]<br>5 13 ms 11 ms 11 ms unknown.Level3.net [209.244.10.245]<br>6 * * * Request timed out.<br>7 * * * Request timed out.<br>8 * * * Request timed out.<br>9 * * * Request timed out.<br>10 * * * Request timed out.<br>11 * * * Request timed out.<br>12 * * * Request timed out.<br>13 * * * Request timed out.<br>14 * * * Request timed out.<br>15 * * * Request timed out.<br><br><br>Trace complete.<br><br>Here is to Speakeasy...<br><br>Tracing route to speakeasy.net [216.254.0.95]<br>over a maximum of 30 hops:<br><br>1 11 ms 11 ms 11 ms dsl081-084-001.lax1.dsl.speakeasy.net [64.81.84.<br>1]<br>2 390 ms 105 ms 337 ms border12.fe4-0.speakeasy-32.lax.pnap.net [63.251<br>.223.91]<br>3 11 ms 11 ms 11 ms core1.ge3-0-bbnet2.lax.pnap.net [216.52.255.65]<br><br>4 11 ms 11 ms 11 ms gigabitethernet5-1-180.ipcolo2.LosAngeles1.Level<br>3.net [63.208.234.133]<br>5 13 ms 13 ms 13 ms gigabitethernet5-0.core2.LosAngeles1.Level3.net<br>[209.244.10.45]<br>6 * * * Request timed out.<br>7 * * * Request timed out.<br>8 * * * Request timed out.<br>9 * * * Request timed out.<br>10 * * * Request timed out.<br>11 * * * Request timed out.<br>12 *<br><br>Obviously I stopped it before I had to go all the way to 30 hops but I think you get the picture. <br><br>I get spikes of up to 28% packet loss in game (at least that I've seen with my own eyes) no matter what time of day that I play. The Blaster worm is expired but yet I saw no difference. It's been five days since I opened my service ticket and I STILL haven't heard from advanced support. Is everyone off this week? Do any of you know what could cause this?<br><br>Oh well, I'm going to bed, I bet in the morning nothing will have changed =(. ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7934567</guid>
<pubDate>Thu, 11 Sep 2003 02:33:44 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7934536</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : He and I go through the same Speakeasy POP in SFO.  See my PP graphs throughout all my Speakeasy threads (click on my username and look at my recent posts); I can guarantee you what he's seeing is identical to what I am.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7934536</guid>
<pubDate>Thu, 11 Sep 2003 02:23:11 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7934259</link>
<description><![CDATA[<A HREF="/useremail/u/458555"><b>ykrad</b></A> : off topic but; hooooly crap.  that is one HELL of a run on!  <br><br>on topic; yeah, pl sucks, especially for gamers.  they're by far the most critical of broadband analyzers.  catskinner, no offense but I suggest you post traceroutes with your comments so they're at least semi-understandable.<br><br>I also go through the Seattle POP and have experienced the pl but haven't been significantly impacted by it.  My roomate plays SW:Galaxies and hasn't expressed any grief with it - except when SE was dropping altogether the other day(s)...<br><br>while I agree it is a pain, I still think SE is doing the best they can.  They wouldn't be the #1 independant bandwidth reseller if they had a bunch of no-nothing network engineer monkeys on staff.  Lets just have a little more faith.  ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7934259</guid>
<pubDate>Thu, 11 Sep 2003 01:29:19 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7932264</link>
<description><![CDATA[<A HREF="/useremail/u/585933"><b>sh0V3L</b></A> : Thats all fine and dandy I think  speakeasy could care less about our ping plotter charts  they know thier system is below par internap sucks  routing is just rediculius  i can see how spiky the network is i have a 768/768 sdsl circuit i run a game server  ok im in sancarlos ca guys in sanfrancisco with a speakeasy dsl connection going through the same pop have a ping of 50 to 80 thats just way to high its 25 miles away yet a tracert reveals 11 or 12 hops internap just flat sux  i trace a game server in sanjose  again just 25 miles away 12 friggin hops abd a ping of 40  hell it shoould be 6 hops a ping of  15 to 20 max  you know that i know that and SE Damn well knows it too  i think the only reason they say send in ping plotter logs is to give you something to do so your not constantly calling  sorry if this offends anyone its not ment as a flame  its reality dont let them fool ya we must demand a cure and this is not a worm issue as i have been trying to rectify this for months  as koitsu has to .<br><br>Speakeasy u know the cure apply it now please]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7932264</guid>
<pubDate>Wed, 10 Sep 2003 21:43:29 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7931761</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Where did you conclude I was "pinging a router and not a host at a POP?"  Not a single graph of mine that I've posted here in the past 2 months has done that -- I test from endpoint to endpoint.<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7931761</guid>
<pubDate>Wed, 10 Sep 2003 20:54:18 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7929205</link>
<description><![CDATA[<A HREF="/useremail/u/168864"><b>sporkme</b></A> :  <BLOCKQUOTE><SMALL>said by  koitsu <A HREF="/useremail/u/659143"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR>I realise SE doesn't filter, but I strongly urge reconsideration -- filtering TCP src port 135, or TCP dst port 135 at the border routers.  Border routers are specifically deployed for this purpose, and it takes less processing time to <I>drop</I> a packet on a Cisco or Juniper than it does to route it.  <br><HR></BLOCKQUOTE><br><br>A few problems with that...  Blaster (or the next worm, or NACHI) doesn't really care if it's being filtered upstream.  It will still blast away out your pc, out your modem, out the dslam, out Covad's ATM network, out SE's backhaul.  SE does not have any real breathing room for this, so they get slammed.  Unlike the cable guys, they can't filter back at your CPE to save their network.<br><br>And depending on IOS, filtering is much more CPU intensive.  On 12.2T(mumble), adding 135 filters gobbled up 20% more CPU, and that is with CEF enabled.<br><br>But I don't think SE has Cisco or Juniper boxes, just a Redback and an FE or GigE handoff to InterNAP.  And from what I've seen, the Redback doesn't get too fancy with filtering...<br><br>Another thing with Redback is that they prioritize ICMP replies *really low*, so pointing pingplotter at the router gives a less accurate picture than say pointing it to a DNS or game server at your pop.  That also gives you more leverage if their network guy knows that pinging routers gives flawed results.<br><br> <BLOCKQUOTE><SMALL>said by  koitsu <A HREF="/useremail/u/659143"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR><br>This is a route change, which is EXTREMELY prominent with InterNAP (I've seen them change routing tables every 30 minutes -- I have no idea what criteria they use to decide when to drop BGP with someone and switch, but it seems almost random).<br><HR></BLOCKQUOTE><br><br>While their PR stance is that they have all these transit connections for "robust connectivity", I think a big part of their decisions are based on closely meeting minimums with each provider to meet certain price points.  Since they went in the crapper, you see almost 0% of traffic going out "expensive" paths.  I think they put the rest of their money into automating route selection based on economic constraints rather than "optimum routing".  No one likes to dis InterNap, but they really aren't that "premium" anymore.  Sorry.<br><br> <BLOCKQUOTE><SMALL>said by  koitsu <A HREF="/useremail/u/659143"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><HR><br> What I want to know is why the packet loss is induced <B>upon my DSL gateway</B> depending upon which route packets are taking at InterNAP.<br><HR></BLOCKQUOTE><br><br>Coincidence?  Or the bgp scanner process is sucking up cpu after a change?  Another reason not to ping a router, but a host at the POP instead.<br><small>--<br><A HREF="http://www.speakeasy.org/~spork">just a minute</A></small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7929205</guid>
<pubDate>Wed, 10 Sep 2003 16:06:08 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7928441</link>
<description><![CDATA[<A HREF="/useremail/u/558803"><b>paulhaskew</b></A> : heh, my modem just lost sync for the third time in two days... hmmm]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7928441</guid>
<pubDate>Wed, 10 Sep 2003 14:39:51 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7927160</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> : I have a feeling that my issue is not worm related, as I am on the Seattle POP. This morning(5:45 am)I am still showing up to 20-30% PL on the 2nd hop of my connection.  In my opinion it sounds like a NOC(Internap) issue for us Seattle POP folks...I just wish we weren't still in the dark.<br><br>Self]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7927160</guid>
<pubDate>Wed, 10 Sep 2003 11:27:58 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7925644</link>
<description><![CDATA[<A HREF="/useremail/u/312284"><b>bhan261</b></A> : www.pingplotter.com<br><br>Also, yesterday was the first day in a month that I didn't have several spikes of P/L.  So maybe it was MSBlaster...I'll keep my fingers crossed.<div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7925644?c=425721&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG TITLE="20597 bytes" BORDER=0 WIDTH=445 HEIGHT=205 SRC="/r0/download/425721~0e8d54517d4580c9e79b55cdee88d530/grapher10.gif"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7925644</guid>
<pubDate>Wed, 10 Sep 2003 07:19:11 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7924941</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : I am out of the LAX pop and I am seeing continuous (throughout the day) packet loss... anywhere from 1% to 28%. I have the Gamer package and have never seen packet loss on my line before last week... obviously this is affecting my gaming =( and although I've contacted support, I'm still waiting for contact from advanced support (it's been three days now). If this truly was related to the worms going around, why is it that nobody else I game with is experiencing any problems? <br><br>And where do you get that ping plotter? ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7924941</guid>
<pubDate>Wed, 10 Sep 2003 01:50:57 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7916493</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Hahaha.  Thanks for the enthusiasm.  ;-)<br><br>Probably not though, since I work today (Tue) and tomorrow.  :-)  I usually close Ping Plotter while using Remote Desktop, but of course the week before last was an exception since I absolutely needed to prove that something strange was afoot at the Circle K.<br><br>I'm hoping that the occasional packet loss shown in our graphs goes away.  As far as Seattle goes, hoo boy, I'm really crossing my fingers on that one.  Just when I thought it was back via SFO, SEA comes along and kicks me to the curb!  ;-)<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7916493</guid>
<pubDate>Tue, 09 Sep 2003 09:40:02 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7916377</link>
<description><![CDATA[<A HREF="/useremail/u/853040"><b>Chicago_DSL6</b></A> : I'll bet koitsu will find out before SE!]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7916377</guid>
<pubDate>Tue, 09 Sep 2003 09:22:14 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7915916</link>
<description><![CDATA[<A HREF="/useremail/u/312284"><b>bhan261</b></A> : Yes...today is the day that we'll find out whether SE's engineers were correct or simply living in hope.  Anyone want to make any bets?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7915916</guid>
<pubDate>Tue, 09 Sep 2003 07:32:11 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7912789</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Latest check from my 1.5/384 ADSL.<br><br>The "huge red blotch" you see from about 16:12 until 17:00 or so is Verio.  I verified this since PP logs route changes.  Why are BGP route changes at InterNAP affecting my DSL gateway?  This makes absolutely no sense to me what-so-ever.<br><br>The "smaller packet loss" lines shown are probably caused by MSBlast and SoBig.F.  That I can justify.<br><br>But I still don't understand why latency shoots through the roof from 09:00 until midnight.  That has absolutely nothing to do with MSBlast or SoBig.F, that's for sure.  Plus, you can see a point in the graph above (a little after 11:00) where the latency dips.  Unless all of these people (and there would have to be a LOT meeting this condition) using the 'net through SE don't leave their PCs from 00:01 until 08:59, and simultaneously suffer from MSBlast.<br><br>Tomorrow is 09/09.  MSBlast stops working after that point in time.  If what's being shown here (from everyone) continues past that, my vote is that it has absolutely nothing to do with MSBlast.<br><br>EDIT: Typos.<br><SMALL>--<br>Making life hard for others since 1977.</SMALL><br><br><i>[text was edited by author 2003-09-08 21:00:26]</i><br><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7912789?c=424708&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="19909 bytes" WIDTH=600 HEIGHT=473 SRC="/r0/download/424708.thumb600~d1cec27ab5e4b99a8c44188cab819683/se_broke_4.png/thumb.jpg" ALT="Click for full size"></A><br>SE SFO, 09/08</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7912789</guid>
<pubDate>Mon, 08 Sep 2003 20:58:12 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7911928</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> : Kat-<br><br>Any update on the Seattle POP?<br><br>Self]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7911928</guid>
<pubDate>Mon, 08 Sep 2003 19:31:24 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7888853</link>
<description><![CDATA[<A HREF="/useremail/u/696918"><b>Endorphine</b></A> : Is the Seattle POP outage/problems related to the blaster worm, or the other reason you didn't tell us yet? :)<div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7888853?c=422710&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="27208 bytes" WIDTH=600 HEIGHT=474 SRC="/r0/download/422710.thumb600~7d789335cca3595b39b5bcd6218413ce/ping.symantec.com.png/thumb.jpg" ALT="Click for full size"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7888853</guid>
<pubDate>Sat, 06 Sep 2003 00:18:28 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7886317</link>
<description><![CDATA[<A HREF="/useremail/u/758754"><b>brikholl</b></A> : I'll 2nd those that don't think that the blaster (or variants) is the root cause of these issues. Partially, maybe, but not entirely.<br><br>I had been seeing problems before my initial call to support way back last month. I just waited a few days to call in, hoping it'd get better.<br><br>I've since left SE (was in the 30 day trial at the time) and am really surprised that not only is the issue still going on, but that it's worse now than it was when I had SE.<br><br>I've moved to another provider, and see NONE of these issues anywhere. What I find interesting is that at times I'd be routed with SE over just about the same path I take to places at my new ISP, and while I saw massive PL when at SE, I see none now.<br><br>Lastly, Kat does a great job, but the folks on the phone need to stop spouting the "it's your line, not us" stuff. Covad came out and checked my line, stating it's fine. My current ISP is running flawlessly on it. I'm glad to see that in Kat's post they seem to be heading in that direction, so that's a good thing.<br><br>Overall, I thought that for the premium price I was paying for SE, that the techs on the phone should have followed through with things better. Rather than always playing the "blame game" with Covad or my line. I mean, I didn't know Covad was coming out until I called SE to request a status update and was told "yeah, Covad is coming out tomorrow." No one called me to tell me that. I wouldn't have been home if I hadn't called in. :)<br><br>But, for the week or so the service worked "right" it was great. ;)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7886317</guid>
<pubDate>Fri, 05 Sep 2003 19:08:33 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7884452</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Excellent update, Kat.<br><br>I did take router load and pipe saturation into mind when considering the situation.  30-50% sounds a little high, to be honest (I would guess more along the lines of 20-25%), but I won't argue because I simply don't have access to the networking equipment: period.<br><br>I realise SE doesn't filter, but I strongly urge reconsideration -- filtering TCP src port 135, or TCP dst port 135 at the border routers.  Border routers are specifically deployed for this purpose, and it takes less processing time to <I>drop</I> a packet on a Cisco or Juniper than it does to route it.  Don't respond with ICMP_UNREACH_PORT or ICMP_UNREACH_ADMIN_PROHIBIT: just silently drop the things, both directions.  If there are customers who are ACTUALLY RELYING on RPC, unfiltered, across their connections, they need to get a grip on security and start using a VPN with IPsec.<br><br>If this is indeed the <A HREF="http://securityresponse.symantec.com/avcenter/venc/data/w32.blaster.worm.html">W32.Blaster.Worm</A>, then I can conclude the following from my graphs:<br><br>If you notice, most of the heavy (80-100%, "large red blocks") packet loss appears in sections.  If you examine the latency (black line), you'll see it takes a sharp ramp or dip simultaneously.<br><br>This is a route change, which is EXTREMELY prominent with InterNAP (I've seen them change routing tables every 30 minutes -- I have no idea what criteria they use to decide when to drop BGP with someone and switch, but it seems almost random).  From examining my data files for all of this, I've found that ,ost of the heavy packet loss sections are caused <B>when routing through Verio</B>.  Being as I <I>worked</I> for Verio for over 3 years, this comes as no surprise -- they refuse to filter ANYTHING ANYWHERE, regardless if their entire network is being hit (that includes DoS/DDoS), and they don't play very well with end-users, ISPs, or other peering providers.<br><br>I don't know what kind-of agreement you have with InterNAP, but it might be wise to request that Verio be taken out of the BGP table for SE netblocks until this can be resolved.  The "lingering" packet loss you see in the other portions of my graphs I can accept being caused by the Blaster variants.<br><br>What I want to know is why the packet loss is induced <B>upon my DSL gateway</B> depending upon which route packets are taking at InterNAP.  The only explanation I can come up with is that the DSL gateways have multiple interfaces, and while one interface may be saturated, the other is seemingly fine (only noticed on a BGP change).  If this is the case, alright, but still pretty odd.<br><br>P.S. -- Don't forget <A HREF="http://www.symantec.com/avcenter/venc/data/w32.sobig.f@mm.html">W32/SoBig.F</A>, which I guarantee is giving routers a work-out as well.  Luckily the thing terminates itself on 09/09.  W32.Blaster.Worm stops working between January 1st and August 15th (but good luck getting people to put up with this for another 4 months).<br><small>--<br>Making life hard for others since 1977.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7884452</guid>
<pubDate>Fri, 05 Sep 2003 15:21:29 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7884444</link>
<description><![CDATA[<A HREF="/useremail/u/312284"><b>bhan261</b></A> : I will admit that this isn't my area of expertise, but if it IS a result of the Blaster worm, wouldn't I be seeing similar problems on my work connection?  (NYConnect T1) I'm not.  Wouldn't my wife see it on her work connection?  (DSL.net T1)  She's not.  <br><br>As I said, I am not an engineer so Blaster could very well be the problem.  It just seems odd.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7884444</guid>
<pubDate>Fri, 05 Sep 2003 15:20:55 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7884197</link>
<description><![CDATA[<A HREF="/useremail/u/457359"><b>MrCoal</b></A> : I think it is a cop out to blame these problems on the Blaster worm.<br><br>I have had intermittent severe packet loss for WEEKS, long before Blaster started appearing. <br><br>In my case, my connection will just suddenly start experiencing packet loss <I>throughout the internet</I>. This can occur anytime and lasts for several minutes, then just as mysteriously, the packet loss goes away and everything works great again. <br><br>Sometimes I can not even reach many sites. Lowering my MTU to 1400 helps but I still get intermittent packet loss. <br><br>I am just living with it, but there must be some underlying routing problem.<br><small>--<br><br>MrCoal<br>Crystal Lake, IL</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7884197</guid>
<pubDate>Fri, 05 Sep 2003 14:51:22 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7884012</link>
<description><![CDATA[<A HREF="/useremail/u/354856"><b>yoonix</b></A> : Thanks for a very useful and detailed post, Kat, good to see that Speakeasy is looking into this issue. And not so good to see that worm writers are responsible for this. :(]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7884012</guid>
<pubDate>Fri, 05 Sep 2003 14:23:56 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7883821</link>
<description><![CDATA[<A HREF="/useremail/u/183624"><b>Yourself</b></A> : Thanks for the update Kat!!  Given the fact that I am on the Seattle POP, I am actually intrigued by the first paragraph of the update and look forward to the next bit of info(it's like a soap opera :) )<br><br>Self]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7883821</guid>
<pubDate>Fri, 05 Sep 2003 13:56:11 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7883595</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : <B><U>UPDATE</U></B><br><br>We met last night and this morning about the packet loss and latency reports in a few of our POPs.  We have a separate, unique concern and overriding issue in our Seattle POP that is still under investigation, so I cannot speak to that at this time &#150; but I can say that the issue under investigation is only being exacerbated by the root cause of the issue across our network.<br><br>The crux of it is this:  The MSBlaster worm and variants have caused an increase in unnecessary traffic by 30% - 50%, depending on the POP.  This is impacting Speakeasy&#146;s network and the Internet as a whole &#150; resulting in both monitored packet loss and increased latency Internet-wide.<br><br>The original report, by brikholl on 8/7, was due to the circuit transitions that we performed in SFO on 8/6 and 8/7.  From the information he provided, it appeared that the connection returned to normal and then the packet loss and latency increase returned on 8/13, two days after the MS Blaster worm was identified and began propagation.<br><br>Due to the worm activity, you may see degraded service during peak hours.  This is not due to bandwidth constraints but rather to maxing out how many packets the router can forward per second.<br><br>The monitored packet loss graphs displayed in this forum recently tell part of the story, but can be misleading.  Routers and servers treat &#147;ping&#148; (ICMP traffic) with a very low &#147;handle&#148; priority.  In practice, this means that if a given router is busy handling other traffic, it can delay the response or even decide not to respond (which appears as packet loss).  While some of our POPs have high usage during a few hours in the evening, San Francisco is one of our largest markets and has a high concentration of heavy usage throughout the day.  Add the unnecessary worm traffic to this usage pattern and the dropped packets will increase accordingly.  The general rule is that as long as you are reaching your destination host with no packet loss, or only a small jump in latency, you are <I>not</I> being affected by the current state of things.  Latency will probably be higher than usual until these worms die down.<br><br>Regarding the SBC connection posed by koitsu & brikholl awhile back &#150; We read through these threads and it appears that SBC is also seeing a significant hit due to these worms.  At one point, a rep states that they isolated this into one of the routers in one of their CO's and that it was resolved, but we have no further information on the state of this.<br><br>If SBC was having problems with equipment related specifically to their DSL services, our customers shouldn't have been impacted at all.  However, if the problems were related to their backbone/Internet services, we may have seen some impact, assuming Internap was routing through SBC at the time &#150; which is highly unlikely.<br><br>So, that&#146;s the diagnosis &#150; this is what we&#146;re doing to fix it:<br><br>Our abuse team is notifying customers reportedly infected with this worm and will work with them to secure their network.  We&#146;re going to aggressively work this until we can reduce the number of infected computers on our network by at least 75%.  Industry experts have stated that this worm has peaked and is on the decline, although we haven&#146;t seen any real world evidence of that quite yet.<br><br>As you know, we are in the process of a major network upgrade and will be deploying equipment that allows us to be more resilient during situations like this in the future.<br><br>We have informed our support staff of this outstanding, global network issue and requested that while they are troubleshooting specific connections, they keep this in mind.  We want to avoid any more of the &#147;it&#146;s your LAN, nothing we can do&#148; and any unnecessary frustration on the part of the customer if at all possible, but still continue to troubleshoot connections to determine if there is <I>another</I> issue, unrelated to the worm, at hand.  <br><br>We are continuing to monitor and work on this situation and I&#146;ll post any additional updates here. <br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7883595</guid>
<pubDate>Fri, 05 Sep 2003 13:25:26 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7880725</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Agreed.  I cannot even imagine how SDSL customers are putting up with this for how much SDSL costs.  I've personally now moved to my Comcast modem until this can be resolved.<br><br>Graph shows what's happening; large gray portion is due to me simply not running PP during that time (I was doing some hardware work on my workstation).<br><br>I also began witnessing the "stalling socket" problem I've documented here on the forum a few times (which leads me to believe that the problems I had with it back when I was 1.5/768 were the beginning stages of this whole thing!).  It also took me a good 10-15 full minutes to download a battle.net update for Warcraft 3 (something that should take about 2 minutes max), due to all the packet loss.<br><br>Sadly, if it's not fixed by the end / near the end of this month, I'm going to have to cancel.  Two months of this is just unacceptable, and I'm sure Kat can understand our frustrations.<br><br>I'll power up my DSL bridge a couple times a week to see how things are doing.  I may end up sticking a spare gateway I have (Netgear RP614) on my DSL line just so I can run mtr against it from my co-lo to see if there's ever any improvement (otherwise a tr just times out due to nothing listening on the IP).<br><SMALL>--<br>Making life hard for others since 1977.</SMALL><br><i>[text was edited by author 2003-09-05 02:27:51]</i><br><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7880725?c=422145&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="22879 bytes" WIDTH=600 HEIGHT=468 SRC="/r0/download/422145.thumb600~333e30831e006955c7043356118b0cf4/se_broke_3.png/thumb.jpg" ALT="Click for full size"></A><br>SE, evening 09/04</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7880725</guid>
<pubDate>Fri, 05 Sep 2003 02:26:39 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7878520</link>
<description><![CDATA[<A HREF="/useremail/u/585933"><b>sh0V3L</b></A> : Im really fed up i have regulars complainig about lag ( i run a ut2003 game server btw )  i dont blame the my connection is getting worse by the min  when will they take this serious ive had and have tickets  open  nothing gets done same thing everytime  from our side things are fine lol what an answer  so check this out  &raquo;<A HREF="/quality/nil/1152730">/quality/nil/1152730</A> <br><br>that really suxorz the sour cho cho man  FIX IT GUYS!!!!!!!!!!!!!!!!!!   THIS is an sdsl 768/768 circuit here  $$$$<br>GET IT RIGHT  please <br>FED UP!!!!!!!]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7878520</guid>
<pubDate>Thu, 04 Sep 2003 21:54:24 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7876357</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Graph above is the past 13 hours -- while I was sleeping (and no, I don't leave any applications running like P2P apps and that sort-of thing).  The fact that the PL goes away for hours then suddenly comes back again is proof to me that there's either an oversaturation or equipment problem <I>somewhere</I>.  My vote is still the DSLAM.  The other part that bothers me is the increasing average latency from 09:00 to midnight -- it doesn't make any sense why a network would increase in latency _over 20ms_ unless their equipment and/or network capacity was oversaturated.  Just my opinion, of course.<br><br>I don't go the hosting route; I have actual co-location for that.  :-)  All I want here in the Bay is 1.5mbit down and 384kbit up (or higher -- but those are my minimum requirements).  The download speed is pretty much a standard by now, and the upstream I mainly require for a) a fast Remote Desktop connection while at work, and b) being able to stream mp3s from my home box while at work (I use 96-320kbit VBR, so 256kbit upstream induces stuttering on occasion)).<br><br>So far SE has gone to great lengths to provide me with pretty much everything I need, including renegotiating my line speed (I was originally 1.5/768 syncing at 1.5/540 and had occasional sync problems, now I'm 1.5/384 -- but all of these network problems were still apparent throughout that fiasco too).<br><small>--<br>Making life hard for others since 1977.</small><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7876357?c=421812&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="23626 bytes" WIDTH=600 HEIGHT=480 SRC="/r0/download/421812.thumb600~8c1797f3ca7907db48dd68defd57a04c/se_broke_2.png/thumb.jpg" ALT="Click for full size"></A><br>09/04 @ 02:00 to 15:30</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7876357</guid>
<pubDate>Thu, 04 Sep 2003 18:34:55 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7871460</link>
<description><![CDATA[<A HREF="/useremail/u/853040"><b>Chicago_DSL6</b></A> : Koitsu, I hope they at least waive the cancellation fee. I am glad that there is an end user in these forums that DOES actually know what they are talking about. The fact that you have presented this much information about your problem and still not gotten your issue resolved in unreal. I never wanted to go to the dark side (SBC), but I called them yesterday for status on install (moved over the weekend) and they mentioned how ALL of their DSL customers are getting doubled downstream. I do not know what you need your DSL connection for, but if it isn't for hosting, SBC might be your most "reliable" and inexpensive choice.<br><br>Again, nice work koitsu and best of luck!]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7871460</guid>
<pubDate>Thu, 04 Sep 2003 09:29:52 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7870972</link>
<description><![CDATA[<A HREF="/useremail/u/312284"><b>bhan261</b></A> : Koitsu,<br><br>I don't know whether you are a saint or an idiot to endure this kind of poor service without some sort of offer for reduction in fee from SE.  I (and others) are having problems in NYC but nothing this extreme.<br><br>But you are right that a continuing flow of information about what's being done to investigate and resolve the problem will go a long way to maintaining the peace.  Let's hope SE follows through accordingly.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7870972</guid>
<pubDate>Thu, 04 Sep 2003 07:58:10 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7870653</link>
<description><![CDATA[<A HREF="/useremail/u/204244"><b>warcorp</b></A> : YIKES!<br>Nope can't beat that.  We are broken, but not THAT broken....]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7870653</guid>
<pubDate>Thu, 04 Sep 2003 05:48:16 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7870631</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Can you beat this?<br><br>This has been going on since about 23:30 or so.  Prior to that, it was what I'm used to seeing (flippant latency, occasional packet loss (3-4%)).<br><br>You know we're sad individuals when we're comparing results of broken connectivity!  :-)<br><small>--<br>Making life hard for others since 1977.</small><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7870631?c=421477&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="18622 bytes" WIDTH=600 HEIGHT=388 SRC="/r0/download/421477.thumb600~1517b51da36976e9235c2180a36ff713/se_broke.png/thumb.jpg" ALT="Click for full size"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7870631</guid>
<pubDate>Thu, 04 Sep 2003 05:37:03 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7870597</link>
<description><![CDATA[<A HREF="/useremail/u/204244"><b>warcorp</b></A> : Koitsu,<br>We seem to be having the same problem out of the Chicago POP as well so I feel your pain.  Not nearly to the degree you are however and seems to be a problem starting at about 7:30 and going all the way till 4:00am ish the next day and it's regular as clockwork (for the past 4 or 5 weeks that I know of.  This is the last 12 hours:<div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7870597?c=421474&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="5654 bytes" WIDTH=600 HEIGHT=186 SRC="/r0/download/421474.thumb600~e3a785826e9b6f14805f592631b6a1af/pplot.png/thumb.jpg" ALT="Click for full size"></A></TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7870597</guid>
<pubDate>Thu, 04 Sep 2003 05:10:34 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7870578</link>
<description><![CDATA[<A HREF="/useremail/u/659143"><b>koitsu</b></A> : Very thankful for this, Kat.<br><br>You -- and this post of yours -- are literally the reason I am still a customer.  I had just logged in to MySpeakeasy to file a cancellation (yes, after all the hard work you, myself, and lots of other reps have put into dealing with the issues I've brought forth), but remembered I hadn't checked the SE forum in a week or so.  I'm thankful I did.<br><br>The problem I have with all of this is that it's confusing SE's engineering crew. I <B>am</B> an engineer (system and networking), and have been since 1991.  I guess I'm having trouble accepting that an engineering group simply can't pinpoint what/where the problem is.<br><br>I know you've probably heard all of this before, but it's just that, well... we're going on, what, almost 5 weeks of this now (in regards to SFO)?  It's becoming hard to stomach.  I shake my head every day when I stare at my graphs and see the same repetitious behaviour and over between the hours of 09:00 and midnight.  I keep waiting to see some change in it, even something as trivial as the Window-of-Doom being audited to something smaller (or heck, even LARGER!).<br><br>To make matters worse, as of this evening, things have seemingly become downright foul.  It's nearly 2 in the morning and I'm witnessing packet loss (huge margins might I add, suddenly appearing out of no where in clumps of literally 35-40%!), as well as the flippant latency all of us have been reporting.  It's the first time I've ever seen it happen at this late of an hour.  I even tried power-cycling my DSL bridge: no love.<br><br>I'm presently on my Comcast connection, but good lord -- you can tell from the graph I've posted just how absolutely HORRID Comcast is right now here in the Bay.  This has been a long-standing problem with AT&T and Comcast for over <B>3 years now</B>, and it's getting worse.  It's been confirmed as well: it's over-saturation due to the populus here.<br><br>Despite my comments, I'm going to continue sticking with SE for as long as I can.  It's just that... *sigh*... SBC doesn't seem to be having problems like this, or rather, at least not to this degree.  I'm sure you can understand my frustration.<br><br>Please keep us updated, even with small things like "there was an engineering meeting today about this."  I just like knowing someone is at least acknowledging what we're seeing as legitimate, since we (customers) fought so hard to get SE Support to accept this issue in the first place.<br><br><SMALL>I haven't forgotten about your orchids either, by the way.  I'm still keeping my word on getting you some.  I just happen to be swamped due to work, and a lazy person to bat.</SMALL><br><small>--<br>Making life hard for others since 1977.</small><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#000000 nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/7870578?c=421473&ret=L2ZvcnVtL3I4MDg1NDA2LnhtbA%3D%3D"><IMG class="apic" BORDER=0 TITLE="24102 bytes" WIDTH=600 HEIGHT=443 SRC="/r0/download/421473.thumb600~8edc32c1708298eb1971fc667d4efdc0/comcast_bay_area.png/thumb.jpg" ALT="Click for full size"></A><br>Comcast, Bay Area</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7870578</guid>
<pubDate>Thu, 04 Sep 2003 04:59:42 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7869537</link>
<description><![CDATA[<A HREF="/useremail/u/696918"><b>Endorphine</b></A> : Thanks for the update Kat!<br><br>Hope they figure out what is going on with the border routers.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7869537</guid>
<pubDate>Thu, 04 Sep 2003 00:21:27 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7866956</link>
<description><![CDATA[<A HREF="/useremail/u/672749"><b>JonW</b></A> : There are lots of problems all around the internet lately, I assume the multiple worms going around haven't quite been defeated.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7866956</guid>
<pubDate>Wed, 03 Sep 2003 20:11:53 EDT</pubDate>
</item>

<item>
<title>Re: Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7864877</link>
<description><![CDATA[<A HREF="/useremail/u/151802"><b>jaykaykay</b></A> : Great and glad to hear it.  While I have not posted to this forum about my packet loss and latency problems, I have done so on the site.  I am glad to note that it is a wider problem than just my own, and since I haven't been able to spend much time here of late, I hadn't even checked this forum.<br><small>--<br>JKK:-)Age is a very high price to pay for my maturity. If I can't stay young, I can at least stay immature!  </small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7864877</guid>
<pubDate>Wed, 03 Sep 2003 16:15:36 EDT</pubDate>
</item>

<item>
<title>Packet Loss/Latency Reports</title>
<link>http://www.dslreports.com/forum/remark,7863751</link>
<description><![CDATA[<A HREF="/useremail/u/473126"><b>KatOak</b></A> : Just a quick update here:<br><br>Many of you have provided excellent information regarding the packet loss and/or latency that you are either monitoring or directly experiencing in your Point of Presence.  <br><br>I have passed all account information to our Engineering team and they are thoroughly investigating this situation at this time.  I'm hopeful that we'll have more information to provide within the next couple of days.<br><br>We really appreciate the time that many of you have spent tracking and reporting this problem as it has been extremely helpful.<br><small>--<br>Kat Oak <BR>Speakeasy<BR>kat@speakeasy.net</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,7863751</guid>
<pubDate>Wed, 03 Sep 2003 14:18:55 EDT</pubDate>
</item>

</channel>
</rss>
