Worst Explanation From Tech Support?

Disgruntled-with-Tech-Support asks: "Let's face it: At some point or another, we've had to deal with some form of tech support. Quite often, it's a hit-or-miss experience depending on the level of support required. Occasionally, strange, bizarre, or nonsensical explanations result from the problems reported, such as this one: I had just had DSL installed, only to find it much slower than the 56K line I was looking to get rid of. On calling the provider, I was told (by someone who likely reading off cue cards) to visit one of their internal websites for measuring bandwidth. While there, I observed that they had both bytes per second and bits per second listed, and that the number of bytes/sec != bits/sec * 8, rather a factor around 13 or 14. I pointed this out as a possible problem, and the guy's reasoning: 'Uh, it looks like the bytes are getting through to you ok, but the bits are getting stuck someplace.' What was your worst explanation from tech support?"

Comments

Not to mention the submitter has it backwards

[mlyle]

at the number of bytes/sec != bits/sec * 8, rather a factor around 13 or 14.

Shouldn't it be bits/sec = bytes/sec * 8? ;)

Re:"it's a feature, not a bug."

[jdreed1024]

One time I called Redhat for tech support in getting a RH to run on a laptop. I was told, "LCD's don't have scan rates and frequency settings like CRT's do."

I almost went through the phone to choke the bastard.

Uh, only problem is, he was mostly right. While LCDs do in fact have scan rates and frequency settings, no one cares, since they're mostly fixed. Almost all LCDs (at least in the home user market) have a 60 Hz vertical refresh rate. And most LCDs have a fixed resolution, so the scan rate is fixed (it is derived from vertical refresh and resolution). So he mostly knew what he was talking about, assuming the question was "How do I configure XFree86".

Now, if the question was "Can I install Linux on a laptop?" and the answer was "No, because LCDs don't have scan rates", then that's pretty stupid. But that's not clear from the post. Also, how long ago was this? It wasn't that long ago that Linux on a laptop required a lot of kludging, especially to get X running.

Re:Iomega support sucks ass!

[Gatton]

YES they would charge the card. I had a Zip drive and had to call for tech support because Windows 95 wouldn't recognize it. I had to pay $14.95 just to speak to a person. A few years later I received a letter in the mail saying that I was able to join a class action lawsuit against Iomega.

Details here:
http://news.com.com/2100-1023-208214.html?l egacy=c net

Bits about Bytes

[Anonymous Coward]

actually in asynch serial comms (such as your 56K) a byte is data bits, plus start, stop, parity bits
so the old standard 8,n,1
is really 1 start bit, plus 8 data bits, no parity bit, and 1 stop bit
so 10 bits in this case
the largest commmon byte would be something like
8,e,2 (1 start+8+1(for even)+2 stop bits, thus
12 bits in that byte as transmitted.

The LISA daemon could be your problem

[adrenaline_junky]

I had this EXACT same problem with my ISP. It turned out that the LISA daemon that comes standard with Mandrake (dunno about other distros...) burps out ICMP pings over your network. My ISP took his ICMP ping traffic to be port scanning and/or some MS-Blast virus, and disconnected my connection. The bastards finally turned it back on once I tracked down exactly what was generating this (very minor) ping traffic.

Re:no, not in this decade.

[Kaemaril]

In the 1960's, yes. Now, no, not really

Tell that to Unisys. Their mainframes (at least the ones I have to use) still have their 36 bit architecture, hence a 9 bit byte. Unusual? Yep.

Re:Worst Explanation?

[edremy]

Serious answer: they probably had a number of small planes in the queue and your plane would have caused too much wake turbulence for them. They could hold you and let a bunch of small guys take off, or let you go and hold up a half dozen planes.