PDA

View Full Version : Transfer speed dropped to nothing!!



MacJunkie
03-28-2006, 12:26 PM
Hi all.

I have 2 tivo series 1s with turbonet cards.

I have been extracting shows for a long time without any problems..until a few days ago.

I have always had good transfer speed but a few days ago my speed dropped to practically nothing (.01).

This is on both of my Tivos.

I have done all of the standard network/pc troubleshooting, so I don't think there are problems there. I get good speed from the internet.

I have Tytool 10.3 and 10.4 and and the new tyserver (also have the older version).

The show list comes over as fast as it always has but when the xfer starts, the speed is gone.

10.3 and 10.4 act exactly the same way now with either version of tyserver.

It would now take 8 hours to transfer a 30 minute show.

I have reloaded the Tytool app on the pc and updated cygwin.

Does anyone have any suggestions?

Thanks!

eastwind
03-28-2006, 03:22 PM
Sounds like a hardware problem. I know you have "done all of the standard network/pc troubleshooting" but I don't know what you think that is. Are both TiVos attached to the same network? Did you recently change the router? Are you using static or DHCP? What is the address for each TiVo and the router and the PC you're transferring to? Do they have different MAC addresses? Have you tried a crossover cable? Is there more than one router/switch/hub to deal with? If so, have you tried eliminating any of them?

I guess I'm asking, "What exactly have you done and has anything changed that you've might not think matters?"

ew

MacJunkie
03-28-2006, 06:25 PM
EW,

Thanks for the reply. The reason I said that I had done all of the standard stuff is because people usually reply with "check the cable" or some other basic troubleshooting that has nothing to do with the actual problem.

I support computer networks for a living, so I'm sure that it's not a network problem. It may be a hardware problem, but whatever it is, happened to two Tivos at the same time. I have changed ports on the switch.

The computer runs just as fast on the network on both of the Tivos ports so that rules out the switch. There is one switch, one router (which they don't use because they are connected to the switch) and static ip addresses for everything.

I haven't changed anything on the network. Both Tivos just dropped to nothing on xfer speed at the same time. since the computer is still running just as fast, that rules out the PC network connection.

I haven't tried a crossover cable yet because the Tivos are on the other end of the house from the computer, but I will try that to see what happens.

I guess I was just wondering if anyone knew of a recent Tivo software update that may have caused the problem.

Both Tivos are still able to do the daily call via the network and haven't reported any problems.

eastwind
03-28-2006, 07:59 PM
AFAIK, there haven't been any updates the the SAS1s for some time. Not sure about the S1 DTiVos as I don't have any of those. Check the version from the System Information Screen if you're in doubt.

Any chance you've checked the TyTool Networking options to see if it sees more than one IP and is using the wrong one? (I don't think you'd get any transfer at all in that case, but who knows?) Haven't recently installed any VPN-or PCAnywhere-like stuff have you?

ew

Narf54321
03-28-2006, 10:48 PM
I support computer networks for a living, so I'm sure that it's not a network problem. It may be a hardware problem, but whatever it is, happened to two Tivos at the same time. I have changed ports on the switch.


Not to sound callous, but being in an 'expert' position puts you more at risk to miss the simple stuff. Last week I was having a similar issue with slow Tivo transfers, came to find out one of my neglected PCs in the corner apparently decided to freak out and tie up the network hub so nothing else was getting bandwidth. (Yeah, OK so I use cheap hardware instead of a managed switch at home).

My favorite story was the one of the campus research labs, where for the longest time they couldn't figure out why there were so many packet retransmits and problems on one particular subnet. This was back in the day when you need an external transceiver to rig up your ethernet network... Turns out somebody had at one time plugged said transceiver into the 15-pin joystick port on one of the project PCs. This went on for over a year I think, mainly because it was one of those situations where nobody really knew what that particular machine was for, and so nobody turned it off or checked it.

MacJunkie
03-29-2006, 11:05 AM
Thanks for the response Narf54321.

I have narrowed the problem down to something on the PC.

I get great network speeds on everything except Tytool.

I reloaded the Tytool app from a fresh download, but still get the same results.

I'm going to try a different PC this weekend to see if the problem is resolved.

The Tytool app appears to only use the files in the Tytool directory and cygwin, both of which have been reloaded.

I have changed network ports and ip addresses too, so I don't know what else to try. I also used a crossover cable but it didn't help. I use firewall software so I disabled it but that didn't help either.

Thanks for all of the replies.

Jamie
03-29-2006, 11:16 AM
...
and the new tyserver (also have the older version).

The show list comes over as fast as it always has but when the xfer starts, the speed is gone.

10.3 and 10.4 act exactly the same way now with either version of tyserver.
...I'm not sure if this was just a typo, or if you are confused, but tytools uses a tivo-side server process called "tserver" not "tyserver". tyserver is part of tystudio.

MacJunkie
03-29-2006, 03:56 PM
It wasn't really a typo. I just called it the wrong thing.

I am using 2 versions of tserver on my Tivo. I have them named different things so I can keep up with the version numbers.

I have always just used the Tytool package.

I only run one version at a time. I get the same results with either version.

Thanks!

jt72
03-29-2006, 08:36 PM
I'm having similiar problems, but not as bad. For the past couple years I've been getting around 2.70 meg/sec download speeds using tserver & tytools. I haven't done much for a while, but when I went to download the last month's worth of shows I've only been able to get 0.90 meg/sec.

I have not made any changes to either system (that I can remember), and have spent the last couple hours trying everything that I can think of. I've re-downloaded both tytool & tserver. Uploaded the latest tserver to my tivo and nothing seems to help.

I've tried several different versions of tserver (mfs_tools), and the ones packaged with tytool9r18, 10r1, and 10r4. I've also tried those three versions of the tytool client also.

Any help would be greatly appreciated.

Gary

EDIT: Just used Windows Task Manager to check network performance, and noticed that my NIC was set to 10 mbps full-duplex (troubleshooting step for linksys router problem). Changed back to Full Autonegotiation (100 mbps full-duplex). Everything working fine now.

PEC1968
04-11-2006, 09:33 PM
EDIT: Just used Windows Task Manager to check network performance, and noticed that my NIC was set to 10 mbps full-duplex (troubleshooting step for linksys router problem). Changed back to Full Autonegotiation (100 mbps full-duplex). Everything working fine now.

I have a similar issue. After checking just about everything, I changed my hard-coded NIC from 100MB FD to Autodetect just for grins. My speed jumped from .07 to 2.2 instantly!!

Thanks for thread!

ocntscha
04-12-2006, 08:58 AM
I have a similar issue. After checking just about everything, I changed my hard-coded NIC from 100MB FD to Autodetect just for grins. My speed jumped from .07 to 2.2 instantly!!

Thanks for thread!Sounds like the switch port is autonegotiating. You shouldn't have had your NIC forced to full duplex without having the other end, the switch port, forced also. What ends up happening is the NIC is full duplex since you've forced it that way, the switch doesn't know what to do since you've prohibitted the NIC from autonegotating by forcing it, so the switch defaults to half duplex. You end up with the NIC end at full duplex and the switch end at half, a mismatch, it'll "work" but you'll get aweful performance just like you witnessed.

In my experience when the ends of the link are mismatched like that, generally what I've seen is the throughput in one direction will be fast, practically normal even, while throughput in the other direction will be horrendously slow.

If you can't force, or aren't going to force, your switch port to full duplex then never force the NIC end to full duplex. And of course by the same token, if you've forced a switch port to full duplex then always force the NIC that's using it to full duplex as well.

Jamie
04-12-2006, 09:42 AM
Sounds like the switch port is autonegotiating. You shouldn't have had your NIC forced to full duplex without having the other end, the switch port, forced also. What ends up happening is the NIC is full duplex since you've forced it that way, the switch doesn't know what to do since you've prohibitted the NIC from autonegotating by forcing it, so the switch defaults to half duplex. You end up with the NIC end at full duplex and the switch end at half, a mismatch, it'll "work" but you'll get aweful performance just like you witnessed.

In my experience when the ends of the link are mismatched like that, generally what I've seen is the throughput in one direction will be fast, practically normal even, while throughput in the other direction will be horrendously slow.

If you can't force, or aren't going to force, your switch port to full duplex then never force the NIC end to full duplex. And of course by the same token, if you've forced a switch port to full duplex then always force the NIC that's using it to full duplex as well.I suppose it depends on the driver, but, in my experience with the linux drivers I've looked at, when you "force" a speed and/or duplex, the driver still goes through MII autonegotiation, but it "advertises" only the forced values, instead of its full suite of capabilities. So, if everything is working properly and the drivers are written correctly, the autonegotiation on the switch side should still work. Granted, there may be drivers out there that don't work this way. And, of course, if you force full duplex, but the other side is a hub that only does half duplex, autonegotiation will fail.

cheer
04-12-2006, 11:33 AM
Negotiation is, from what I've observed, one of those "things." You may be right, Jamie, about what the linux drivers advertise when forced, but of course there's no guarantee that Windows drivers are that smart. Plus, many switches can be hit-or-miss in negotiation -- so my preference is to force everything if I can. Admittedly, I don't always have that luxury.

Oh and another way to catch duplex mismatches is CRC errors -- Cisco routers will show loads of CRC errors on the LAN interface when there's a duplex mismatch.

ocntscha
04-12-2006, 12:13 PM
I suppose it depends on the driver, but, in my experience with the linux drivers I've looked at, when you "force" a speed and/or duplex, the driver still goes through MII autonegotiation, but it "advertises" only the forced values, instead of its full suite of capabilities. So, if everything is working properly and the drivers are written correctly, the autonegotiation on the switch side should still work. Granted, there may be drivers out there that don't work this way. And, of course, if you force full duplex, but the other side is a hub that only does half duplex, autonegotiation will fail.I'm not going to dispute that, in fact I'm sure its accurate. But just relaying my personal experience with Sun servers and Cisco switches.. The way Sun tells you to force a NIC is to actually turn off its autonegotiation option in the driver and disable all the capabilities except what you want. If you disable autonegotiation in the driver but do have multiple options enabled, like 10 full, 10half, 100full, 100half, the driver will use the "highest" choice.

Now I don't do the Cisco switch configuration so maybe it doesn't have to be this way but when our networking group configure a switch port to 100mb/full the port will no longer engage in an autonegotion conversation. So unless the NIC using that port is also force to 100/full you'll end up mismatched like I described in my previous pst. Again though, maybe thats just the way our people are configuring them

Now I've never really dug into it to deeply but just casual contact with some of the Windows driver configuration guis and observed behavior leads me to believe at least in general Windows network drivers won't continue to engage in an autonegotiation conversation if you've forced a speed/duplex.

Jamie
04-12-2006, 01:41 PM
I'm not going to dispute that, in fact I'm sure its accurate. But just relaying my personal experience with Sun servers and Cisco switches.. The way Sun tells you to force a NIC is to actually turn off its autonegotiation option in the driver and disable all the capabilities except what you want. If you disable autonegotiation in the driver but do have multiple options enabled, like 10 full, 10half, 100full, 100half, the driver will use the "highest" choice.

Now I don't do the Cisco switch configuration so maybe it doesn't have to be this way but when our networking group configure a switch port to 100mb/full the port will no longer engage in an autonegotion conversation. So unless the NIC using that port is also force to 100/full you'll end up mismatched like I described in my previous pst. Again though, maybe thats just the way our people are configuring them

Now I've never really dug into it to deeply but just casual contact with some of the Windows driver configuration guis and observed behavior leads me to believe at least in general Windows network drivers won't continue to engage in an autonegotiation conversation if you've forced a speed/duplex.Yeah, I didn't mean to dispute your experience; just offering another point of view. Most cheap home-grade switches are unmanaged and always autonegotiate. There is no way to force them to a particular speed/duplex except by forcing the link partner on the other side. But, as you say, this may not always work, so it's better to stick with full autonegotiate on both sides of the link.

cheer
04-12-2006, 01:51 PM
Now I don't do the Cisco switch configuration so maybe it doesn't have to be this way but when our networking group configure a switch port to 100mb/full the port will no longer engage in an autonegotion conversation.
Absolutely true -- Cisco switches (and routers), when hard coded to a particular speed and duplex, do not do any autonegotiation at all.