YouTube Video uploading

[#1]

do you both use quicktime or the google uploader service ?

if the answer is yes then that's the reason.
as for the comment about dropping support for XP, M$ has stated that starting on the magic day they will be removing all support pages for XP from there archives (much the same way they did with various other OS's that went passed there support end date) so yes in effect it will be like it never existed in terms of info available on how to do things via M$ hosted boards

[#2]

Just like they did with NT. Panic now.
I notice when he did the Wireshark capture, the OP's MTU was 1470 for some reason, then 1500 when he did he DSLReports Tweak Test.
The TCP stack reset may have done the trick on some other level, but it seems unlikely that a slightly lower than necessary MTU was causing an upload issue. Easy enough to test, however: now it's working again, use DrTCP (or whatever) to set it back to 1470 and see if the issue recurs after a restart.

[#3]

Some web servers may negotiate a lower packet size than the maximum of your connection e.g.:
[tt]84 0.935062 192.168.0.101 173.194.41.154 TCP 38926 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
85 0.955964 173.194.41.154 192.168.0.101 TCP http > 38926 [SYN, ACK] Seq=0 Ack=1 Win=42900 Len=0 MSS=1430 SACK_PERM=1 WS=64[/tt]
The above was copied out of wireshark. It shows my computer opening a connection to 173.194.41.154, and amongst other things, it tells 173.194.41.154 that the TCP maximum segment size (MSS) is 1460. Then 173.194.41.154 replied with a MSS of 1430.
It doesn't mean there's some problem or that you must set your computer's MTU to some lower value. There isn't and you don't need to.

[#4]

Ah, well if that's normal for Google servers, his MTU was presumably 1500 all along. The handshake isn't in the capture info and I made an (obviously incorrect) assumption that it was the OP's PC rather than the server which had determined the lower MSS. In fact, he probably made the offer of 1460 (that's MSS, add 40 for MTU,) as in your capture, ejs, Google countered with 1430 and they settled on the lower of the two as per normal TCP operation.
So nothing has changed re. MTU from the beginning (apart from a very brief flirtation with the FixIt wizard, quickly reversed by the command line reset): and, indeed, there should be no pressing reason to depart from 1500 on PPPoA in normal use.
The question of why the YT uploads were slow remains open, therefore...

[#5]

Quote from: SuperZoom

there should be no pressing reason to depart from 1500 on PPPoA in normal use.

Not strictly true, as using an MTU of 1500 is not an efficient packet size, as it contains unused space packed with 'filler' bytes.
If you choose an MTU that is an exact multiple of the data frame (such as 1478 or 1430, that contain no 'filler' bytes) then your connection will be transferring less bits per packet for the same wanted data payload.  Because you send less bits (for the same amount of data), then this means your true data transfer rate will be higher and your speedtests will be measurably faster.
In addition, if you are connecting over VPN, or some proxies, or some tunnels, then these are known to reduce the effective MTU, and some links have issues reporting the correct values when challenged with MTU discovery packets.  Therefore if you set your router MTU to say 1430, then you are likely to not run into these issues and your connection speed will be faster because you are forcing an efficient packet size at your network boundary.
The values of either 1478 or 1430 are the best values for UK PPPoA/VC-MUX connections,
but I understand that for other connection types that the optimums are -
    1470 for PPPoA/LLC
    1446 for PPPoE over ATM/LLC

[#6]

Some of the benefit gained by optimizing the MTU for the ATM cell packing is negated by the reduction in the amount of useful data that can be carried per IP packet, so you have to transfer more packets, although I think in theory you gain more the you lose. Your speedtests might be measurably faster but in practice you might not notice the difference unless you run lots of speedtests.

[#7]

While that is true, my point really was in response to "no pressing reason to depart from 1500", because for virtually no effort you might as well choose an MTU value that reduces the probability of seeing unexpected connectivity issues and that gives you the best connection speed, by simply setting an appropriate number, and at no risk of making things any worse than with using the default value.

[#8]

There isn't no risk of making things worse, you could make things worse from ending up transferring a larger number of smaller packets, increasing the relative overhead of the IP and TCP headers. It's a minor optimization at best, and I've never experienced any problems from having the MTU set at 1500. And how does having a smaller MTU make you immune from broken path mtu discovery, such that the remote server tries to send you 1500 byte packets?

[#9]

ATM cells are a fixed size, whatever your MTU, so yes, you can avoid sending an extra cell which isn't quite full by trying to make sure your packets exactly fill a certain number of cells.
Great.
Then what happens when the MSS the two sides settle on is different to the MTU you might like to use? Messes up your carefully tweaked efficiency gain.
Not worth the hassle. More convenient to have LAN and WAN MTUs the same and avoid MSS clamping or per-machine config changes.
No pressing reason.
VPNs are a separate issue of no direct import.
It's no big deal if you want to reduce the MTU - go all the way down to 576 for the ultimate in dial-up retro chic! - but there's no pressing reason to on PPPoA except for personal pleasure in feeling you've got the best out of your connection.
And, as ejs says, it can cause problems with some misconfigured websites if you do it via a change at the router and use MSS clamping, because they will send 1500 byte packets in response to your MSS offer of 1460 and then ignore the errors. Not such a problem nowadays, but definitely something to bear in mind with FTTC/P connections using PPPoE if a particular site isn't working.
Anyway, it doesn't change the fact that nothing so far really points strongly towards MTU as being the source of the problem here. That suggestion came from Kelly and people seem to have just run with it.

[#10]

@ super
naw the mtu value is a valid idea its what lead to running the SLI stack rebuild, the fact the problem was cured by running the CLI tends to suggest that something was very wrong either within his registry keys or within the stack values themselves which lead to incorrect handling of the mss and created the very mtu mismatch that was causing the problem

[#11]

err yes that woz it no doubt

[#12]

Quote from: nanotm

do you both use quicktime or the google uploader service ?

I do not use anything 'quicktime'. As for this 'google uploader service'; I'm not entirely sure what you mean. I just upload my videos the same way anybody does on YT. Unless there is some special way that I'm not aware of.

[#13]

hmm your screen cap shows quicktime running, not surprising its part of the bloatware that comes with iphones and ipads
there is an desktop you tube app so its possible you use that to upload stuff instead of the old fashioned click on a webpage and manually select files way....

[#14]

Will you please keep your unsubstantiated opinions to yourself. There is no indication that this has anything to do with QuickTime and just because you had a bad experience in the past does not mean every problem is linked to it.
The majority of users have never seen problems with Apple software on Windoze. In most instances of issues it is usually linked to incompatibility with other third party software.

[#15]

@RPMozley
its not an opinion of QuickTime being responsible, the OP clearly posted a screen cap showing an upload problem where the YouTube page has a big blue banner telling him he needs to optimize QuickTime to improve upload speed, thus indicating that his problem is linked to the use of the programme,
what I suggested is that perhaps he also has the YouTube app and that between them the conflict is caused, I didn't offer an opinion as to why it might be happening, mearly that having such spyware installed it is unsurprising its causing problems.
and yes I do know pretty much all companies track stuff, but most of them don't create a backdoor into your pc that pretty much any script kiddy can take advantage of without needing some elaborate website hijacking with specially crafted packets ....