Re: Cat-5 cables near 200 Paul, SF
On May 31, 2013, at 22:36, Tuc wrote: > Thanks to everyone. I didn't pay enough attention the last time this was > discussed, sorry about that. I have my cables, though I need to start > working on my sob story when I put in my expense report for 30 cables that > should have been 1.44 each, not 6.95. So the difference is $165, probably not even 3 or 4 hours of your time. Probably the time spent writing the expense report and sob story is the biggest waste of money. -Geert
Re: Verizon FIOS IPv6?
On Jan 8, 2014, at 17:03, Justin M. Streiner wrote: > I have a tunnel through HE and it is solid. I'm on Verizon FIOS (70/30 Mbit/s), and set up my ActionTec router to allow tunneling traffic through, but am using my Apple TimeCapsule base station (3 years old) for the actual IPv6 tunneling. I've been amazed how rock-solid the IPv6 has been. All traffic between my home and work workplace go over IPv6, and using X11 etc, I'm quite sensitive to latency or packet loss. To my surprise, generally the tunneled IPv6 performs (far) better than IPv4: --- .gnat.com ping6 statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 15.204/16.911/18.721/0.941 ms This really is good latency, especially considering the tunnel. Note that my MacBook Pro is using a WiFi connection, adding a millisecond or two as well. --- ping statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 26.280/28.259/31.289/1.254 ms This is fine, but not great. The Apple Base station does NAT-ing, but did the same for my previous DSL link to Bway, which had <16ms ping times, so I can rule out NAT-related delays. At this point in time I'm not holding my breath for VZ to do anything to accommodate IPv6 or provide good routing, and know that if, for my company or otherwise, I'll have an option to chose HE, I will. -Geert PS. Today I changed my FIOS autopay method with VZ (as somehow they ignored the info I gave at signup) and got notified it would take up to 60 days (!!!) for the changes to take effect. Clearly, VZ is (and always will be) a phone company.
Re: Verizon FIOS IPv6?
On Jan 9, 2014, at 14:32, Stephen Frost wrote: > Sure, entirely possible, but I'd be investigating into why because > clearly there's a better ipv4 route than that being used, if ipv6 > tunneled over ipv4 is faster. A bit of difference is fine, but it > sounded like more than 'a bit'. Of course it's a routing issue. At AdaCore (AS32019), we have very good connectivity with level3 (<2ms), but the Verizon/Level3 path seems variable and generally slow. Here are the relevant bits. Note that I've seen lots of different routings for IPv4 traffic, routing over Cogent, Alter.net, Above.net, but not so much when using the HE tunnel. Of course, I could just ascribe this to NSA traffic redirection/inspection, or some traffic engineering by a New Jersey governor, but I guess VZ might have their own reasons for subpar routing. It always seems as if VZ is avoiding L3. The Hurricane Electric tunnel server I'm using is 209.51.161.14. kwai:~%ping -i0.2 -c20 209.51.161.14 ... --- 209.51.161.14 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 3819ms rtt min/avg/max/mdev = 1.604/1.763/2.497/0.205 ms potomac:~%ping -i0.2 -c20 209.51.161.14 ... --- 209.51.161.14 ping statistics --- 20 packets transmitted, 20 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 6.832/8.040/9.152/0.720 ms The sum of these times is just 10ms. Now, look at the resulting time for my IPv4 tunnel endpoint: kwai:~%ping -i0.2 -c20 72.69.184.141 ... --- 72.69.184.141 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 3817ms rtt min/avg/max/mdev = 22.843/25.422/27.725/1.538 ms That's where the difference is. With trace routes: kwai:~%traceroute 209.51.161.14 traceroute to 209.51.161.14 (209.51.161.14), 30 hops max, 60 byte packets 1 jordan.gnat.com (205.232.38.200) 5.402 ms 5.483 ms 5.535 ms 2 towerstream-gw.gnat.com (69.38.252.177) 2.113 ms 2.119 ms 2.159 ms 3 g4-0.cr.nyc1.ny.towerstream.com (69.38.244.13) 2.253 ms 2.260 ms 2.296 ms 4 br.nyc0203.ny.towerstream.net (69.38.138.110) 3.181 ms 3.190 ms 3.209 ms 5 64.125.173.225 (64.125.173.225) 3.299 ms 3.308 ms 3.394 ms 6 xe-1-2-1.er2.lga5.us.above.net (64.125.31.166) 4.224 ms 2.113 ms 2.123 ms 7 core1.nyc4.he.net (198.32.118.57) 3.733 ms 10.968 ms 10.960 ms 8 tserv1.nyc4.he.net (209.51.161.14) 2.088 ms 1.694 ms 1.870 ms kwai:~%traceroute 72.69.184.141 traceroute to 72.69.184.141 (72.69.184.141), 30 hops max, 60 byte packets 1 jordan.gnat.com (205.232.38.200) 5.888 ms 6.295 ms 6.442 ms 2 towerstream-gw.gnat.com (69.38.252.177) 2.062 ms 2.066 ms 2.108 ms 3 g4-0.cr.nyc1.ny.towerstream.com (69.38.244.13) 2.201 ms 2.206 ms 2.319 ms 4 xe-4-0-1.edge4.NewYork1.Level3.net (4.28.130.57) 3.124 ms 3.129 ms 3.156 ms 5 vlan70.csw2.NewYork1.Level3.net (4.69.155.126) 3.248 ms vlan60.csw1.NewYork1.Level3.net (4.69.155.62) 3.299 ms vlan80.csw3.NewYork1.Level3.net (4.69.155.190) 3.304 ms 6 ae-81-81.ebr1.NewYork1.Level3.net (4.69.134.73) 4.702 ms ae-62-62.ebr2.NewYork1.Level3.net (4.69.148.33) 2.372 ms ae-81-81.ebr1.NewYork1.Level3.net (4.69.134.73) 2.392 ms 7 4.69.201.42 (4.69.201.42) 2.377 ms ae-45-45.ebr2.NewYork2.Level3.net (4.69.141.22) 2.366 ms ae-47-47.ebr2.NewYork2.Level3.net (4.69.201.34) 2.407 ms 8 ae-1-51.edge2.NewYork2.Level3.net (4.69.138.195) 2.369 ms 2.518 ms 2.529 ms 9 po6-20G.ar6.NYC1.gblx.net (208.51.134.113) 18.468 ms 18.474 ms 18.655 ms 10 0.ae11.BR3.NYC4.ALTER.NET (204.255.168.193) 20.372 ms 19.718 ms 17.999 ms 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * *C^Cpotomac:%traceroute 209.51.161.14 traceroute to 209.51.161.14 (209.51.161.14), 64 hops max, 52 byte packets 1 wireless_broadband_router (192.168.1.1) 1.238 ms 0.852 ms 0.805 ms 2 l100.nycmny-vfttp-102.verizon-gni.net (71.190.186.1) 5.275 ms 5.189 ms 5.732 ms 3 g1-15-4-1.nycmny-lcr-22.verizon-gni.net (130.81.218.160) 9.572 ms 7.315 ms 8.120 ms 4 so-3-1-0-0.ny5030-bb-rtr2.verizon-gni.net (130.81.199.12) 7.135 ms ae2-0.ny5030-bb-rtr1.verizon-gni.net (130.81.199.178) 7.228 ms so-5-0-0-0.ny5030-bb-rtr1.verizon-gni.net (130.81.22.18) 7.047 ms 5 0.xe-10-0-0.br3.nyc4.alter.net (152.63.24.109) 7.925 ms 0.xe-11-3-0.br2.nyc4.alter.net (152.63.23.137) 7.892 ms 0.xe-10-0-0.br3.nyc4.alter.net (152.63.24.109) 7.114 ms 6 204.255.168.190 (204.255.168.190) 7.497 ms 10.291 ms 8.601 ms 7 hurricane-electric-llc-new-york.tengigabitethernet1-3.ar5.nyc1.gblx.net (64.209.92.98) 8.228 ms 7.101 ms 17.883 ms 8 tserv1.nyc4.he.net (209.51.161.14) 8.962 ms 8.231 ms 6.681 ms potomac:%traceroute kwai.gnat.com traceroute to kwai.gnat.com (205.232.38.4), 64 hops max, 52 byte packets 1 wireless_broadband_router (192.168.1.1) 4.037 ms 2.140 ms 2.572 ms 2 l100.nycmny-vfttp-102.verizon-gni.net (71.190.186.1) 6.554 ms 7.270 ms 7.757 ms 3 g0-14-3-3.nycmny-lcr-22.verizon-gni.net (130.81.104.44) 11.689 ms 9
Re: Linux Router: TCP slow, UDP fast
On Feb 15, 2009, at 04:24, Chris wrote: Any last ideas appreciated before causing headaches removing switches would be appreciated. The TCP offloading should be suspect. Any current PC hardware should be able to deal with huge amounts of traffic without any offloading. Start with turning that off, so everything will be handled by Linux directly. Even if you still would have a problem, it's easier to trouble shoot without magic black boxes (TOE) in between. -Geert
Re: IPv6 is on the marketers radar
On Feb 11, 2011, at 15:43, Fred Baker wrote: > Anyone that uses a residential router (Linksys, D-Link, Netgear, etc) is > likely to need to upgrade that, most likely by buying a new one. Set-top > boxes are generally IPv4; anyone with a TV is likely to need to upgrade at > least the software. Skype is not yet IPv6-capable, and will need one an > update. "The ISPs will take care of this" is a really empty hope. The ISPs > will take care of their part, but users should expect that there will be > things jiggling over the coming couple of years. Honestly, I can't quite see the big deal for home users. I'm using an Apple Airport Extreme, and setting it up with a IPv6 tunnel from HE was quite straightforward. Sure, I don't expect the average user to go through these steps, but they could easily be automated and rolled out as part of a firmware update (which is a routine matter already) . If larger ISP's provide their own tunnels, they could use private IPv4 space for customers to tunnel IPv6 over, and the only issue would be a few router settings to change. According to test-ipv6.com my home network has now a score of 10/10 for both IPv4 and IPv6. Didn't take very long to do, maybe 10 minutes. Initial speed tests show only a marginal slowdown of IPv6 compared to IPv4. However, if I look at what would be involved at my $dayjob to support IPv6, that would be far more involved. What's more, I cannot justify the cost to support IPv6 only clients, as there are none yet. For the foreseeable future, people will have (NATed or not) IPv4 connectivity, so content providers are fine without IPv6. I won't have to worry about this until most major content providers support IPv6-only clients. So, I think we'll transition to a situation where for some purposes (Skype, gaming, file-sharing) there will be a benefit for (tunneled) IPv6 compared to (NATed) IPv4, but for simple content providers there will still be no incentive to leave IPv4. For the software there is a similar scenario. Clients typically use a web browser or other high-volume popular application. It is easy to add IPv6 support to these. However, content providers use many different pieces to provider their sites, including custom interfaces to databases etc. It's a huge task to make all of those work with IPv6. Again, it seems it is far easier to deal with the relatively homogeneous base of users for IPv6, compared to the fragmented and irregular market of content providers. -Geert
Re: IPv6 is on the marketers radar
On Feb 12, 2011, at 21:03, Lee Howard wrote: >> Honestly, I can't quite see the big deal for home users. I'm using >> an Apple Airport Extreme, and setting it up with a IPv6 tunnel from > > $150? That's a high-powered device compared to most home gateways. Sure, but the same thing is possible with a cheap 6-year-old sub-$50 popular Linksys wifi router, see http://opensystems.wordpress.com/2006/06/01/linksys-wrt54g-ipv6-howto/ for example. The point is that it can be cheap, relatively easy and painless for users to upgrade. Basically, it should not have to cost anything extra to set up new users for IPv6. The same hardware that handles IPv4 today can be programmed to do IPv6. >> the foreseeable future, people will have (NATed or not) IPv4 >> connectivity, so content providers are fine without IPv6. > > Depends on the content. Large-scale NAT is bad for you if you > depend on IP geo-location, or use anti-DDOS measures to limit > number of connections or bits from a single IP address, or use > IP address to report abuse, or blacklist IP addresses, or log the > user's IP address, or try to enforce copyright by reporting IP > addresses of violators, or rate-limit outbound data per address, > or record unique visitors by IP address. > It might als > o increase latency, but probably not so much that > you'd panic. Users don't care about IP geo-location or anti-DDOS measures, or any of the other reasons you list. These are things content providers care about, but they don't get to choose wether their viewers use IPv4 or IPv6. > Except for the most basic, static of websites, content providers > are going to prefer IPv6 over IPv4. I don't know whether web > hosting companies will ever automatically dual-stack the PTA's > website, but at some point it will be easier for them to warn all > their customers and just do it, than to track which customers > asked for IPv6 explicitly. As long as a majority of users come over IPv4, better anti-DDOS measures or anti-abuse procedures for IPv6 are not going to make any difference. "When you DOS my site, please use IPv6, so we can better find out your location and more effectively block your IP address." Users are going to drive adoption of IPv6, if and when they find a "killer-app" where IPv6 can provide usability that (heavily NATed) IPv4 can't. This could be better file-sharing tools, lower latency online gaming, better long-distance video-calling or whatever, as long as the benefits will be worth the relatively small (<$50) investment of money and time. For content providers, as long as 90+% of the net is IPv4 only and essentially nobody is IPv6 only, providing dual-stack support is just adding cost for little or no gain in viewership. Content providers often depend on dozens if not hundreds of pieces of hardware and software to provider their services, so supporting IPv6 is vastly most expensive than it is for users to take advantage of it. In my case, the upgrade to IPv6 was free. There must be many more using an Apple router (any model, Express, Extreme or otherwise) that can upgrade to IPv6 for free. However, I can't list any benefit from doing so, except from going to test-ipv6.com and seeing a 10/10 score. Basically, you have to be a geek to be interested in IPv6. That's got to change, before there will be any meaningful shifts. -Geert
