Re: [CGUYS] Fwd: [Slashdot] Mac OS X Problem Puts Up a Block To IPv6

[tjpa]

On May 6, 2010, at 10:44 PM, Fred Holmes wrote:

Discuss this story at:
   http://apple.slashdot.org/comments.pl?sid=10/05/04/2029255


A headline written by someone frustrated by the slow transition to  
IPv6. The discussion following the Slashdot post is very interesting  
as people debate where the real problem is. Some note that the cited  
report does not provide enough detail to isolate the source of the  
problem and doesn't report anything about Windows performance at all.  
There is a heck of a lot of infrastructure between the server and the  
client. Anything in that long path could be the source of the problem.  
Some of the commentators obviously have long experience and can tell  
you that such problems often lie in unexpected places.


by Savage-Rabbit (308260) writes: on Tuesday May 04, @09:51PM  
(#32093330)
I'm not sure quite what he meant by properly supported in the wild  
but it sounded like he was trying to point out that sometimes you do  
get bugs because you implement things correctly but somebody else  
screwed up their implementation. A while back I had a problem  
connecting Linux and OS X based VPN daemons to some Microsoft VPN  
servers. At first it seemed obvious that this was Apple screwing up.  
After some considerable wiresharking and digging in Apple's source  
code [apple.com] I found out that Microsoft's VPN server sends  
malformed protocol messages which the Linux/OS X based counterparts  
try to parse according to the letter of the specification and exit  
with an error when they run into problems. Not that I'm trying to  
absolve Apple of all blame they can fuck up like everybody else and  
do so regularly, however that doesn't change the fact that it's  
entirely possible to render your software unusable by implementing  
it according to specifications. In a situation like that you can  
either change your software to take the buggy implementation by  
insert name of manufacturer into account or stick to your guns and  
piss off your users.


by ShadowRangerRIT (1301549) writes: on Tuesday May 04, @06:29PM  
(#32091848)
Mostly correct. One additional note: Many ISPs and routers don't do  
IPv6 well. So even in the good IPv6 server, good IPv4 backup case,  
many people will be hitting these delays because their ISP or router  
isn't IPv6 friendly. Since the web server can't force your ISP/ 
router to upgrade, they have a choice. Do they serve only over IPv4  
and get guaranteed performance, or do they move to IPv6 with an IPv4  
fallback, thereby guaranteeing that their site will be dog slow for  
a fixed percentage of their users? We want them to move to IPv6 so  
the transition can occur smoothly over time. But a reasonable  
website operator might put off the move until the absolute last  
second, hoping that more ISPs and routers will be ready when they do  
switch. But of course, if no one is serving content over IPv6, ISPs  
have less motivation to upgrade. Yay Catch-22 situations!



*
**  List info, subscription management, list rules, archives, privacy  **
**  policy, calmness, a member map, and more at http://www.cguys.org/  **
*

[CGUYS] Cox Modem Troubleshooting

[Richard P.]

During the last week, my cable modem for Cox Cable loses its Internet
connection about once or twice a day. When troubleshooting, the light
that indicates the cable connection on the Linksys modem, model
BEFCMU10, is not illuminated. If I reboot the modem, it comes up
fine and I get adequate speeds through the connection. After calling
Cox, the only thing they can offer is a service call for which I will
be charged if it turns out that the problem is after their connection.

I have also noticed a slight degradation in the analog TV signal from
Cox during the last week as well.

Should I just go ahead and replace the modem to see if that makes a
difference? It would be less than the service call.

Suggestions please.

FYI, my Visualware Speed Connection test is:

Test Type:  Application Speed
Location:   USA: Dulles, Virginia
Download Speed: 24652 Kbps
Upload Speed:   3380 Kbps
Speed Consistency:  80 %
Round Trip Time:15 ms
Max Delay:  77 ms
Average Delay:  5 ms
Bandwidth:  24652 Kbps
Max Route Speed:34952 Kbps
Route Concurrency:  1

2 connection problems found, click the  to learn more.

MSTR01: The data flow for this test is too erratic

Although the speed achieved may match expectation for the connection,
a low data flow QoS score means that the data flow between the server
and the workstation was not consistent. There can be several reasons
for this such as data congestion along the route or data loss which
invokes recovery. The lower the QoS percentage, the more erratic the
data flow. Many applications can be severely affected by poor data
flow quality regardless of data throughput speed, for example media
applications such as video or voice may become jerky. Voice (VoIP)
telephony will become garbled. If you suspect that the connection was
in use by another application try running the test again to validate
if the problem is persistent.

 MSMD01: TCP is waiting too long for data

The test recorded a TCP maximum delay that exceeded the natural TCP
forced idle delay as a result of the connection's trip time. This
indicates that there may be problems with consistent data flow between
the server and the client. A poor data flow QoS reading is also likely
if the max TCP delay is much higher in comparisons to the trip time.
Common reasons for this type of problem are packet loss and
duplicates. The test graph view will show the TCP delay over the time
of the test. Height and width of the 'orange' delay line shows the
delay consistency.

Thanks in advance,

Richard P.


*
**  List info, subscription management, list rules, archives, privacy  **
**  policy, calmness, a member map, and more at http://www.cguys.org/  **
*