DvArchive Streaming Problem (possible fix) - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
Closed Thread
 
Thread Tools
post #1 of 35 Old 07-09-2003, 03:57 PM - Thread Starter
Member
 
JohnNadeau's Avatar
 
Join Date: Jul 2003
Location: Coloma, Michigan
Posts: 76
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
When watching a movie streaming FROM DvArchive TO ReplayTV, it would always start locking up/repeating at around 7-10 minutes into the show.

Note: Running Windows XP Home Edition on HP 1600+ Athlon

This problem began AFTER upgrading to Replay Software version 5.

I had tried upgrading my network card drivers and changing various settings in DvArchive without any success.

I then tried TWO other things (below) at the same time to fix the problem. Unfortunately, I'm not sure which of the two did the trick... but the good news is that I'm no longer having the streaming problem.

If anyone else tries these, maybe you could try one, then the other to narrow down the solution.

1) I changed the network settings of the ReplayTV unit from manual to automatic & rebooted... I then changed the network settings back to manual & rebooted.

2) In TCP Optimizer:
I changed the MaxDuplicateACK's to "2" (was "3")
I turned TimeStamps off (was on when tweaking/testing broadband)

I can't help but suspect the TimeStamps since it has caused other problems for me in the past and it seems related to the messages I was receiving in the DvArchive Event Log.

Let me know what you find out!
JohnNadeau is offline  
Sponsored Links
Advertisement
 
post #2 of 35 Old 07-10-2003, 12:15 AM
Member
 
digitize's Avatar
 
Join Date: May 2003
Posts: 31
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I just got upgraded to 5.0 about two weeks ago and find that I can't stream from DVA 2.1 to ReplayTV consistently. Prior to the upgrade all was good. One pattern I was able to reproduce consistently was to start a stream and then after a few minutes stop it and then go an select another remote show to stream from DVA and immediately the ReplayTV unit will reboot. I can do the same thing again and again. If I never use DVA everything works find with ReplayTV. So there is some compatibility problems between ReplayTV and DVA since the upgrade to 5.0. I will try your settings to see if it cures the problems I am seeing.
digitize is offline  
post #3 of 35 Old 07-10-2003, 12:53 AM
Member
 
borgmon's Avatar
 
Join Date: Sep 2002
Posts: 23
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
JohnNadeau,

You are a genius!!

I just changed the TCP MaxDuplicateACK's to "2" and turned off Timestamps

Have been banging on this problem for 2 months now and this mod. seems
to have resolved it.

Thanks again.

You have made my day/night.

p.s

Anyone else tried this yet?
borgmon is offline  
Sponsored Links
Advertisement
 
post #4 of 35 Old 07-10-2003, 07:12 AM
AVS Forum Special Member
 
asinshesq's Avatar
 
Join Date: Mar 2001
Posts: 2,584
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally posted by borgmon
...I just changed the TCP MaxDuplicateACK's to "2" and turned off Timestamps...this mod. seems to have resolved it....
I downloaded tcpoptimizer and it told me that my timestamp was already off and tcp maxduplicateack's was set at 'default'. Why was your timestamp on and what does my 'default' mean? I'll try changing from 'default' to '2' tonight and report back.

Alan
asinshesq is offline  
post #5 of 35 Old 07-10-2003, 09:50 AM
Member
 
cool8man's Avatar
 
Join Date: May 2003
Posts: 198
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 10
Where do you get TCP optimizer and how do you change the TCP MaxDuplicateACK's and turn off Timestamps?
cool8man is offline  
post #6 of 35 Old 07-10-2003, 10:00 AM
AVS Forum Special Member
 
chain777's Avatar
 
Join Date: May 2003
Location: Metro Chicago, IL
Posts: 1,540
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally posted by cool8man
Where do you get TCP optimizer and how do you change the TCP MaxDuplicateACK's and turn off Timestamps?
Link

The settings are on the opening screen (1st tab). Select custom and make the changes.

Seems to be working for me so far, 30 minutes and no freezing. Keeping my fingers crossed as other 'fixes' I tried worked initially, but then the problem came back. We'll see.;)

And, thank you John for the info.:D

--Andy--
chain777 is offline  
post #7 of 35 Old 07-10-2003, 10:00 AM
AVS Forum Special Member
 
asinshesq's Avatar
 
Join Date: Mar 2001
Posts: 2,584
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally posted by cool8man
Where do you get TCP optimizer and how do you change the TCP MaxDuplicateACK's and turn off Timestamps?
when you see things like that, a google search usually does the job.

in this case, try: http://www.wildcards-squadron.com/downloads.htm

Alan
asinshesq is offline  
post #8 of 35 Old 07-10-2003, 10:20 AM
AVS Forum Special Member
 
Jeff D's Avatar
 
Join Date: May 2000
Location: One step ahead of you
Posts: 8,140
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 6 Post(s)
Liked: 15
there are two tcp optimizers, i got the wrong one at first.


This is NOT the right one
http://www.connetica.co.uk/
This is NOT the right one
Jeff D is offline  
post #9 of 35 Old 07-10-2003, 10:28 AM
Member
 
borgmon's Avatar
 
Join Date: Sep 2002
Posts: 23
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
asinshesq,

My default was TCP MaxDuplicateACK = 3
TimeStamps = Off

So basically I only changed TCP MaxDuplicateACK = 2
borgmon is offline  
post #10 of 35 Old 07-10-2003, 10:52 AM
AVS Forum Special Member
 
asinshesq's Avatar
 
Join Date: Mar 2001
Posts: 2,584
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally posted by borgmon
asinshesq,

My default was TCP MaxDuplicateACK = 3
TimeStamps = Off

So basically I only changed TCP MaxDuplicateACK = 2
And that fixed it all by itself?? Fabulous - I'll try it tonight and reprot back.

Alan
asinshesq is offline  
post #11 of 35 Old 07-10-2003, 10:57 AM
AVS Forum Special Member
 
Jeff D's Avatar
 
Join Date: May 2000
Location: One step ahead of you
Posts: 8,140
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 6 Post(s)
Liked: 15
I had tried the UK one first, only a check box for MaxDuplicatACK, no settings. I rebooted thinking maybe I could change it after a restart. No luck.

Then I tried speeguide's tool and my settings were just as described above, no timestamp MaxDuplicateACK at 2.

Running 30 minutes and NO stuttering!

John, THANK YOU!
Jeff D is offline  
post #12 of 35 Old 07-10-2003, 11:39 AM
AVS Forum Special Member
 
asinshesq's Avatar
 
Join Date: Mar 2001
Posts: 2,584
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
So what is MaxDuplicateACK anyway? I gather ack is a data acknowledgement under tcp/ip; what does this setting really do and why does it seem to fix the dvarchive problem? And does setting this to 2 actually hurt in other contexts?

Alan
asinshesq is offline  
post #13 of 35 Old 07-10-2003, 11:47 AM
Member
 
cool8man's Avatar
 
Join Date: May 2003
Posts: 198
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 10
I figured I downloaded the wrong one. Thanks.

My Max Duplicate ACKs was already set to 2 and my timestamp was off. Should I lower it to 1?
cool8man is offline  
post #14 of 35 Old 07-10-2003, 11:58 AM
Member
 
greenall's Avatar
 
Join Date: Feb 2003
Posts: 35
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Just checked my win2k server (I've been having this issue since 5.0 as well), and those two settings were already set as recommended.

Does this not apply to win2k?

Richard
greenall is offline  
post #15 of 35 Old 07-10-2003, 12:20 PM
AVS Forum Special Member
 
Jeff D's Avatar
 
Join Date: May 2000
Location: One step ahead of you
Posts: 8,140
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 6 Post(s)
Liked: 15
My changes were made to win2k.... maybe the UK one did something that was important?! Coo8man did you run it and try with just checking the MaxDuplicateACKs box? I wish I had....

Alan I'm just guessing here....

TCP/IP the sender sends a packet and waits for the receiver to acknowledge the packet was received. The packet also has a timestamp. The timestamp is sent with a packet to the receiver and the reciever then sends back an ACK with the timestamp of the sent package.

There are also ACKs without any data, duplicate ACKs. I have no idea how these happen. I do know that if a sender doesn't get an ACK in a timely manner it assumes the packet was lost or misdirected and sends again.

If the sent packet gets misdirected or delayed the sender may send again, meanwhile the receiver is finally getting the first packet and sending an ACK back. The reciever's first ACK could have also been delayed or misdirected or lost. Each packet can have an equal number of ACKs to the number of packets received. I think this variable limits the receiver to saying "I got packet 12323" only 2 times max.
Jeff D is offline  
post #16 of 35 Old 07-10-2003, 12:26 PM
AVS Forum Special Member
 
Jeff D's Avatar
 
Join Date: May 2000
Location: One step ahead of you
Posts: 8,140
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 6 Post(s)
Liked: 15
If someone is about to try this fix, could you run a little test first? It won't screw anything up an may help us understand what's going on.

Please try this test...
Download the SpeedGuide version and check the settings. Then download the UK version of TCPOptimiser and try the checkbox for MaxDuplicateACKs.
Reboot and see what SpeedGuide's app says as your settings. I'm curious exactly what settings are changed.


Greenall, I'm running win2k sp4, not server and this fixed my system. 1 hour and NO tcp/ip errors, resent packets or anything at all reported via perfmon.
Jeff D is offline  
post #17 of 35 Old 07-10-2003, 12:39 PM
Member
 
cool8man's Avatar
 
Join Date: May 2003
Posts: 198
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 10
Jeff I didn't apply the settings for the UK one. I had a feeling that I had downloaded the wrong program so I didn't want to make any changes with that program.

When you first click on custom settings in the SG TCP Optimizer are the settings it has there your defaults? I don't think they are because the number in the TCP Receive Window in Dr. TCP was different than the number in TCP Optimizer.


Also as an alternative you can make these changes with Dr. TCP can't you?

http://www.dslreports.com/front/drtcp.html
cool8man is offline  
post #18 of 35 Old 07-10-2003, 12:39 PM
Member
 
greenall's Avatar
 
Join Date: Feb 2003
Posts: 35
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Jeff.

I hope if fixes mine. The parameters were already set to 2 and timestamps off, so I just "applied" them again, and rebooted. It just concerns me that those were the settings already there, and I had the problem.

I won't be able to test it out until late tonite. (While I can remote desktop into my server from work, I haven't figured out a way to watch the replaytv remotely (-: )
greenall is offline  
post #19 of 35 Old 07-10-2003, 12:46 PM
AVS Forum Special Member
 
sfhub's Avatar
 
Join Date: Aug 2001
Posts: 9,578
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally posted by Jeff D
I'm curious exactly what settings are changed.
It's changing Tcp1323Opts described here:

https://www.avsforum.com/avs-vb/showt...87#post2398987

and

HKLM\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters \\TcpMaxDupAcks

One reason you get duplicate ACKs is for "Fast Retransmit" When the
receiver gets packet #s beyond what they were expecting, the TCP
stack assumes some packets were lost or dropped. It initiates a fast
retransmit by sending an ACK with the ACK # set to the sequence #
of the packet it was expecting. This short circuits the normal "timeout
then retransmit" behavior of the sender side and causes the sender
to immediately resend the packet. If the sender receives "MaxDupAcks"
it will initiate the "Fast Retransmit" By decreasing this value from 3 to 2,
you are allowing "Fast Retransmit" to be triggered more quickly.

BTW the default for TcpMaxDupAcks is already 2, so I suspect it wasn't
necessary to workaround the streaming problem. I suspect just turning
off timestamps would have achieved the same results.
sfhub is offline  
post #20 of 35 Old 07-10-2003, 12:56 PM
Member
 
kamtom's Avatar
 
Join Date: Jan 2003
Posts: 109
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I only had a few brief moments over lunch.. But I downloaded the TCP optomizer and changed the ACK setting from "Default" to 2...watched 19 minutes of Farscape wtih no stuttering... (normal skips happened around 10-12 minutes) So.. hopefully this fixed the issue...

TOM
kamtom is offline  
post #21 of 35 Old 07-10-2003, 01:01 PM
Member
 
cool8man's Avatar
 
Join Date: May 2003
Posts: 198
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Liked: 10
Quote:
Originally posted by greenall
I hope if fixes mine. The parameters were already set to 2 and timestamps off, so I just "applied" them again, and rebooted. It just concerns me that those were the settings already there, and I had the problem.
I'm not sure that those are the default settings. When I clicked on custom settings my TCP Receive window said 256960, but when I checked Dr. TCP it says 64240 for TCP RWin. The Max DupAcks also had no value in Dr. TCP, but said 2 in SG TCP Optimizer. I know that the Dr. TCP settings are correct so I'm thinking that SG TCP Optimizer isn't telling you your current settings when you click on custom settings.
cool8man is offline  
post #22 of 35 Old 07-10-2003, 01:20 PM
AVS Forum Special Member
 
sfhub's Avatar
 
Join Date: Aug 2001
Posts: 9,578
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally posted by borgmon
asinshesq,

My default was TCP MaxDuplicateACK = 3
TimeStamps = Off

So basically I only changed TCP MaxDuplicateACK = 2
I found that TCP Optimizer incorrectly assumes if Tcp1323Opts is not
present in the registry (the default condition) then "Window Scaling" and
"Timestamps" are turned off. This is *not* true. If the option is not
present, then Windows will never "Ask" for "Timestamps" to be used,
but the person who initiates the connection (your RTV unit) can request
"Timestamps" be used and Windows will then use "Timestamps"

If you explicitly turn off "Timestamps" by adding Tcp1323Opts=0 or 1,
then Windows will not use "Timestamps" for it's packets even if the
RTV unit requests.

This coupled with the default for TcpMaxDupAcks already being 2, leads me
to believe turning off "Timestamps" is the critical change necessary.
sfhub is offline  
post #23 of 35 Old 07-10-2003, 01:28 PM
AVS Forum Special Member
 
Jeff D's Avatar
 
Join Date: May 2000
Location: One step ahead of you
Posts: 8,140
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 6 Post(s)
Liked: 15
TCPOptimiZer (SG's) doesn't have a default value that is uses, it uses whatever the system is configured as.

I ran a test, I set TCPOptimiZer to MaxDuplicateACK to 3 and timestamp on. Restarted and looked at the settings, still 3 and no timestamps.

I used TCPOptimSer and set the MaxDuplicateACK check box, unchecking everything else. Then I rebooted again.

This time TCPOptimiZer shows MaxDuplicateACK at 2 and timestamps off, reflecting the changes TCPOptimiSer made.

So it looks like both applications will do the trick, I'd like for somoene who hasn't tried anyting to give the UK version a check first, if possilbe, please??? It would be good to know if that app's one option would work too. Cool8man and myself accidently used it before finding the other one, maybe there will be others?

I was going to try enabling timestamps to see what happens....
Jeff D is offline  
post #24 of 35 Old 07-10-2003, 01:28 PM
AVS Forum Special Member
 
j.m.'s Avatar
 
Join Date: Dec 2002
Posts: 2,337
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 10
"Microsoft Windows 2000 TCP/IP Implementation Details"
http://www.microsoft.com/TechNet/its...asp?frame=true

Code:
Tcp1323Opts 

Key: Tcpip\\Parameters 

Value Type: REG_DWORD—number (flags) 

Valid Range: 0, 1, 2, 3 

0 (disable RFC 1323 options)
1 (window scale enabled only) 
2 (timestamps enabled only)
3 (both options enabled) 

Default: No value; the default behavior is as follows: do not
initiate options but if requested provide them. 

Description: This parameter controls RFC 1323 time stamps and
window scaling options. Time stamps and window scaling are
enabled by default, but can be manipulated with flag bits. Bit 0
controls window scaling, and bit 1 controls time stamps.
and

Code:
TcpMaxDupAcks 

Key: Tcpip\\Parameters 

Value Type: REG_DWORD—number 

Valid Range: 1–3 

Default: 2

Description: This parameter determines the number of duplicate ACKs
that must be received for the same sequence number of sent data
before fast retransmit is triggered to resend the segment that has
been dropped in transit. This mechanism is described in more detail
in the "Transmission Control Protocol (TCP)" section of this paper.
These settings are the same on Windows Server 2003 and presumably on Windows XP since it is Win2k-based (I can't find a MS tech paper on XP TCP/IP). Thus, based on this, it looks like that if either of these two settings is really is solving the problem, it must be the TCP1323Opts one (i.e. turning off timestamps).

BTW, if you are not comfortable editing these values in the registry, you can change both of these settings (and others) with Dr TCP, a free <100k download at http://www.dslreports.com/front/drtcp.html that I trust infinitely more than most of these Internet optimizer type programs.

j.m.'s ReplayTV Tools
Home of WinDVA, the Win32 DVArchive launcher
j.m. is offline  
post #25 of 35 Old 07-10-2003, 01:32 PM
AVS Forum Special Member
 
sfhub's Avatar
 
Join Date: Aug 2001
Posts: 9,578
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally posted by cool8man
I'm not sure that those are the default settings. When I clicked on custom settings my TCP Receive window said 256960, but when I checked Dr. TCP it says 64240 for TCP RWin. The Max DupAcks also had no value in Dr. TCP, but said 2 in SG TCP Optimizer. I know that the Dr. TCP settings are correct so I'm thinking that SG TCP Optimizer isn't telling you your current settings when you click on custom settings.
When you click on "custom settings" for SG TCP Optimizer, it applies
its "Optimal" settings, then allows you to make modifications to them.
As you said, it is *not* displaying your default values when you use
"custom settings"

BTW TCP Receive Window of 256960 is *not* possible unless you also
turn on "Window Scaling" (ie Tcp1323Opts=1 or 3). Otherwise you are
limited to RWIN of 65535.
sfhub is offline  
post #26 of 35 Old 07-10-2003, 02:26 PM
AVS Forum Special Member
 
Jeff D's Avatar
 
Join Date: May 2000
Location: One step ahead of you
Posts: 8,140
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 6 Post(s)
Liked: 15
Quote:
Originally posted by j.m.
Thus, based on this, it looks like that if either of these two settings is really is solving the problem, it must be the TCP1323Opts one (i.e. turning off timestamps).
I found that the timestamp is the only value that is important to change.

j.m. or sfhub, wouldn't lowering MaxDuplicateACK from 3 (if you didn't have the default 2) to 2 actually increase the likelyhood a retransmit will occur? As I understood it, if you get 2 out of sequence packet ACKs then you will retransmit the missing packet. If it were 3 (some said it was three to start with) there would another packet's worth of transmit time to be sure a packet was previously lost. Or do I misunderstand what this means?
Jeff D is offline  
post #27 of 35 Old 07-10-2003, 03:12 PM
AVS Forum Special Member
 
asinshesq's Avatar
 
Join Date: Mar 2001
Posts: 2,584
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Anyone have a theory why this timestamp setting was not a problem until we got software version 5.0?

Alan
asinshesq is offline  
post #28 of 35 Old 07-10-2003, 04:27 PM
Member
 
greenall's Avatar
 
Join Date: Feb 2003
Posts: 35
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Yep, it looks like turning off Timestamps did it for me as well. I've never been able to reliably stream with 5.0 until now..

Now I can finally catch up on all those Farscape episodes I've been stashing away.
greenall is offline  
post #29 of 35 Old 07-10-2003, 07:50 PM
AVS Forum Special Member
 
sfhub's Avatar
 
Join Date: Aug 2001
Posts: 9,578
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally posted by Jeff D
wouldn't lowering MaxDuplicateACK from 3 (if you didn't have the default 2) to 2 actually increase the likelyhood a retransmit will occur?
...
As I understood it, if you get 2 out of sequence packet ACKs then you will retransmit the missing packet.
Well, technically lowering TcpMaxDupAcks from 3 to 2 would only increase
likelihood of Fast Retransmit occuring if packets are being lost or dropped.
If the network is smooth running and not overstressed, there wouldn't be
packets dropped or lost so there would be no increase in likelihood of
Fast Restransmit. Lowering from 3 to 2 lowers the threshold for Fast
Retransmit to occur and allows Fast Retransmit to start quicker, assuming
packet loss or drop. However, this is not a bad thing. If the packet
is really lost or dropped, you want the restransmit to happen quicker.

One other thing to consider is TcpMaxDupAcks is *not* present in the
registry by default. It's default value is 2 (even though the entry is
not present). If you have a TcpMaxDupAcks registry entry, either you
put it there or some program (possibly tcp optimizer type) put it there.
There should be no reason your default is 3, as the default is to not
have the registry entry present.

The way normal retransmits occur is for the sender to have a Retransmit
Time Out (RTO). If it hasn't received an ACK for a particular packet in
that timeframe, it'll retransmit. However, many times, the receiver can
figure out it has missed a packet quicker than RTO and there is a way
to short-circuit the RTO timeout period. The receiver can send ACKs with
with the ACK # set to the sequence # of the missing packet. Receiver will
send multiple ACKs of this format. Once the sender sees TcpMaxDupAcks
it'll retransmit that packet. If packets are being loss or dropped, this
feature will smooth out overall performance.

This is all academic as you guys have confirmed our suspicions that
TcpMaxDupAcks was a red herring (I think the Original Poster also
mentioned this)
sfhub is offline  
post #30 of 35 Old 07-10-2003, 08:07 PM
AVS Forum Special Member
 
sfhub's Avatar
 
Join Date: Aug 2001
Posts: 9,578
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:
Originally posted by asinshesq
Anyone have a theory why this timestamp setting was not a problem until we got software version 5.0?
Sure, lots of theories, those are dime a dozen :) The packet analysis
to figure out which theory is the right one takes more effort.

The way timestamps work is to attach a timestamp to each packet and
constantly monitor the ACKs to calculate the RTT (round trip time) If the
RTT starts increasing, the packet transmit rate is throttled back. If
timestamps are not used, the tcp stack will take a sample for each
window of data sent to calculate RTT.

1) It's possible there are just bugs in the implementation of timestamps
in the 5.0 vxworks tcp/ip stack and/or how it interacts with Windows tcp/ip
stack
2) It's possible v4.5 vxworks tcp stack never requested Timestamps so
it wasn't used in the past, so it was a non-issue.
3) It's possible v5.0 is simply dropping packets because it is too busy doing
something else or due to some bug. This could cause the RTT to increase
and the windows tcp stack to throttle back the connection.

I think there are other problems with streaming that are being hidden
by turning timestamps off. For example, even if windows throttles back
the connection, it should eventually start going faster again. The expected
behavior would be some stuttering and pausing, but not continuous
stuttering (which is what I though I had read in some posts) That's
something for DNNA to worry about. What's important for you folks is
DVA streaming works smoothly. I'm glad you guys were able get your
streaming working well again.
sfhub is offline  
Sponsored Links
Advertisement
 
Closed Thread ReplayTV & Showstopper PVRs

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off