MVP can be crashed 'on demand' ...

[lektrikpuke]

I've dabbled with several VMwares and they are very limited peripheral wise. You'd be much better off going with a dual boot system.

[lektrikpuke]

Anybody make it work yet? If so, how?

[Narflex]

We have confirmed now that this is due to a bug in the TCP implementation on Windows Vista. I have an Ethereal trace to support it as well. Vista does not reliably retransmit lost TCP packets in a timely fashion. Sometimes it can take up to 30 seconds for Vista to do a TCP retransmit of a lost packet; which is completely out of spec for a high-speed LAN connection (it should be on the sub-second level). SageTV happens to have a 30 second timeout in the UI socket that disconnects and kills the MVP connection. We're going to increase it to work-around the disconnect; but it'll still cause random 30-seconds hangs when Vista decides not to properly retransmit lost packets. Microsoft is aware of this problem and are working on a fix. You can find more discussion on the same issue here:

http://forums.whirlpool.net.au/forum...fm/720119.html

We've had some luck changing the TCP Retransmission Timeout in the registry (seems to make it take a lot longer to have the problem). But we haven't found a solid workaround yet.

Here's a screenshot of the Ethereal capture that shows the issue:


Frames 4482, 4483 are the packets that Vista (192.168.1.100) sent to the MVP (192.168.1.114); that the MVP did not acknowledge (i.e. it dropped the packets which is 100% OK for TCP). Then you can see even 17 seconds later at frames 10018 and up; that the SEQ numbers on the Vista side are out of sync by 48 bytes. So both endpoints clearly can see that there's been packet loss of 48 bytes from SEQ 1111480 to 1111528. It's the responsibility of Vista in this case to do the retransmit. If we go down to frame 14772 we can see the MVP at that point re-sends the ACK from before back to Vista with some SACK flags set to indicate there was lost data. Then Vista finally sends the lost packets to the MVP at frame 14776 (30 seconds after it was initially sent). The packets that are missing from this trace are for the video connection; this trace is just showing the UI connection using the TCP Follow Stream feature of Ethereal.

This trace clearly shows Vista taking 30 seconds to retransmit a lost TCP packet on a LAN.

[lektrikpuke]

Jeff,

Thanks for the follow up.

I figured it was primarily a communication error, because I kept seeing the MVP rebooting. I used to work with the engineering department (for a company I won't list) that ran across a similar problem with timeouts on communication failure (I believe it was called the "watchdog."). That was embedded in the firmware of the remote device and was programmable.

Any way, thanks again for the follow up, and here's hoping MS pulls their thumb out.

[JParedis]

Jeff,

Thanks very much for this feedback, now I know at least it's not me (again ). Hope MS will correct this soon.

Will the work around, an increase in Sage time-out, be something I have to change myself somewhere, or will there be a Sage 'fix' release? If it's the registry update you mention

Originally Posted by Narflex

We've had some luck changing the TCP Retransmission Timeout in the registry (seems to make it take a lot longer to have the problem). But we haven't found a solid workaround yet.

which registry field do I have to update, and into what?

Thanks and regards,

Jan

[sagesupport]

Here is the location of the Registry setting.

http://www.windowsitpro.com/Articles...5004.html?Ad=1

[carlgar]

Originally Posted by sagesupport

Here is the location of the Registry fix.

http://www.windowsitpro.com/Articles...5004.html?Ad=1

If this is an official response, then why don't you provide the official value to be used? The article only states how to change it. How can support say it is a fix if everyone chooses their own value to be used.

[lektrikpuke]

I put in 5000 (for 5 seconds) as my first try as the article said 3 was the default, and it seemed to work for about 10 minutes (much longer than it had ever done on Vista). I'm going to play some more with the settings once I can get my son off the TV.

As I understand it, this is only a work around, not a fix (even though it's listed as a registry fix). The fix will not come until MS does something about their TCP stack.

I'm happy to see some progress (thanks guys at Sage), but I'm still mad that MS would sell an OS that has problems with communications. I understand all products will have problems in the beginning, but what does MS think computers do besides communicate?

Who do I contact at Microsoft to get a refund?

[JParedis]

I'm not sure what else is influencing this problem, because I'm reading that the gravity of this issue is very different user per user. If I understand lektrikpuke, it happens after max 10 minutes. Myself, I can watch a complete movie, but seem to get into trouble when giving commands to the MVP (FFW, menu navigation etc.). So I suspect other factors to be in the game.

Would like to get confirmation if following, not being a network specialist, is correct. Often I get the error as per scenario:
* Watching a movie and FFW.
* The OSD comes up and I see the scrolling displayed. Hit PLAY.
* The OSD remains (does not go away) and the timer is 'blocked'. The movie itself however continues playing.
* I than know that shortly after the MVP reboots. That seems to match the 30 seconds limit.

Is it so that the movie itself continues playing ok because this is not TCP/IP but UDP (I guess) and that protocol is streaming data, not using ACK's? So no time-out in this?

Another question to increase my understanding. Where does SageTV have the 30sec timeout? On the MVP or in the HTPC service?
I ask because I do not fully understand the work-around. If I understand correctly, the MVP hits the 30 sec TCP/IP time-out and reboots (or is it SageTV on the HTPC that triggers this reboot?). If this registry value changes the time-out of the VISTA TCP/IP time-out, it only makes sure that this part does not time-out after 30 sec. But it does not ensure the MVP gets a timely message (within 30 sec's), so the MVP would still time-out.

I'm clearly missing something in the actual flow of who's doing what. If somebody could explain this a bit, wouild be highly appreciated (always keen to learn and improve my understanding).

Regards,

Jan

[lektrikpuke]

Okay, I realize it's MS fault. We all know that because the software worked just fine with XP. Besides, there's the ethereal capture. So, please don't think I'm blaming you guys at Sage.

My question is this: UDP is used to broadcast (no ack) to the client (extender), and TCP is used for queries and avoiding the reboots. Why can't the host (server) break momentarily (here and there) to listen/respond for/to the TCP? I have to believe the collisions are occurring with the UDP (as I have nothing else running on my network).

Is that a workaround that you guys could implement till MS does something on their end?

Sorry if I'm doing some backseat engineering.

[lektrikpuke]

Has MS specified any kind of release date for a fix? Has anyone been able to use the workaround successfully?

[coryking]

At least I'm not going crazy! I'll make those registery changes sometime this week and report back what values seem to work best.

Is there a knowledge base article for this bug? The closest I could find was related to ACK's but seemed to have nothing to do with retransmits:
http://support.microsoft.com/kb/823764/

[JParedis]

Indeed, I would also be interested to get an MS ack (knowledge base number or alike) of this VISTA issue. As long that doesn't exist, remediation may not be for tomorrow.

Jan

[lektrikpuke]

http://support.microsoft.com/kb/932170

[lektrikpuke]

I have been N/G'ing this as well as watching this forum thread, and I received this reply from someone:

There might be a fix in SP1 but this kinda isnt a bug though, when copying a file on windows previously it would max`s out the motherboard transfer speed and slow windows down on older hardware. This thing "was" designed to fix these problems by slowing down any transfers while something else was using the system, if you kill the task explorer.exe and use another desktop manager the system cant reduce these operations.

So MS (according to the above) did this on purpose.

[bcjenkins]

Interesting.. So if you have a dedicated client machine, presumably you could set the shell to sageclient.exe?

B

[JParedis]

Ok, I'm getting slightly lost here

Is my understanding correct that in VISTA, MS did build in a TCP 'delay' which kicks in 'at certain moments' to ensure a large file copy to another device (characteristics of devices can be found in the MS KB) would not slow down the VISTA running PC?

If yes, is than the issue I and others are experiencing the fact that SageTV's service seems to trigger sometimes this 'at certain moments', resulting in the TCP 'delay' and reboot of the MVP?

If again yes, would any of the proposed workarounds help (read somewhere they didn't)? Has anybody tried?

Jan

PS: still not sure why the MVP reboots because the HTPC does not respond in time.

[lektrikpuke]

Okay, before anyone gets upset, let me qualify the preceding and present post: I got this off a newsgroup. Take it with a grain of salt.

Okay, that said, as I understand it, the MVP reboots because there is a timer (in the software) that tells it to reboot if it doesn't get a response in a certain amount of time. This is put in there (I'm basing this on prior experience with proprietary hardware/software that I have worked with) so just in case the MVP goes into a loop or there is some problem (hardware or software) the reboot can reset everything (and hopefully everything will work correctly again).

Below is another response from the same person that I got the original response from on the newsgroup. I'm going to try it. Here again, take this with a grain of salt, and good luck!!

*************************

The "new" software would run on any hardware new or old, the problem
with the tcp stack is its not compadible with anything because most
companys use industry standards not some customised version. The
origianl functionality is still there because there are tcp/ip options
to disable this. "new" crap.

Give this program from steve jobs a try...
'KezNews Forum :: View topic - Vista Network Helper v1.5 (New 10-5-07)'
(http://keznews.com/forum/viewtopic.php?t=6974)

Some uses of this program are.....
Disable TCP Auto-Tuning can be used to solve following proplems:
* Poor intermittent network performance.
* Slow network loading.
* Unable to open and load some websites or webpages using Internet
Explorer or Firefox, where the blue loading bar keeps running for a long
time, but the pages fail to load.
* Java applets fail to download a and open.
* Cannot receive email or download from POP3 mail server by email
clients such as Thunderbird.
* No mail arrived although users may see the message ''receiving 1 of 3
messages'', and eventually the receiving process will time outwith the
error number 0×800CCC19 timeout.
* Slow email sending or retrieval using Thunderbird and other clients.


NEW Change TCP/IP Connection Limit: (Based on Defcon's patch and code)

*Once installed you can have 70,000 half open connections, these
connections are temp connections anyways.
* You can change the limit to any setting you want.
* By increasing the limit you will be able to speed up P2P (Peer 2
Peer) applications like µTorrent, BitTorrent, BitComet, Azureus,
BitSpirit, eMule (eDonkey network), BearShare, Direct Connect, DC++,
ApexDC++, or even P2PTV such as PPLive, PPStream, Sopcast, TVAnts, Peer
to Peer, Web server, FTP, and many other applications. Basically, it
will make Torrents faster as well as all these other apps you need.

[lektrikpuke]

I decided to buy another copy of XP. I'll wait and see if something is done.

[JParedis]

Originally Posted by lektrikpuke

Okay, that said, as I understand it, the MVP reboots because there is a timer (in the software) that tells it to reboot if it doesn't get a response in a certain amount of time. This is put in there (I'm basing this on prior experience with proprietary hardware/software that I have worked with) so just in case the MVP goes into a loop or there is some problem (hardware or software) the reboot can reset everything (and hopefully everything will work correctly again).

That would clarify current behaviour. The MVP does not get a TCP/IP return in due time and reboots for that reason. Changing the TCP Retransmission Timeout in the registry as suggested would have no effect as that's on the HTPC and will not ensure timely TCP/IP return.

Guess the timer is part of the MVP's OS, not part of the actual software running on it (that would beat its purpose, ensuring a reboot in case of hardware/software problems). Else it would be just a matter of adjusting this time-out in the MVP downloaded Sage software. Have to check if this is also a problem with the Hauppauge software (will check their message board).

I did try the software in your link and disabled the TCP Auto-Tuning + changed TCP/IP Connection Limit to 70000. Did reboot HTPC and MVP (unplug power so it's a cold boot), but still had the reboot.

Well one thing is sure, this is not VISTA ready

Jan