KB4100375 Windows 10 Insider Release Preview Build 17133.73 - Apr.10 Insider

LEOPEVA64 said:

For those who like to experiment, you can use the MCT to create the ISO with the leaked XML file, you just have to download the current MCT, then put the XML file in the same folder and run this command: MediaCreationTool.exe /Selfhost
All the credits to abbodi1406 from MDL.

MBAM just blocked the XML from your link.......

LEOPEVA64 said:

Edit, the link is secure and the file that is downloaded is also safe.

I can verify this, it's a simple text file formatted with XML tags.

LEOPEVA64 said:

I downloaded the ESD of my edition (2.8 GB) at the same speed that I always downloaded the UUP files with the miniserver, I had no problems.

Leo,

What did you do to the test that I cannot see in this post? it is grayed out, and I can only read it when highlighting it (or quoting it to reply)?





Did you actually use the color gray?

This is using the Dark Wide theme for the board....

slicendice said:

I just downloaded Windows 10 Pro x64 v1803 Build 17133.1 EN_US using UUP-Dump mini server and here are the stats from my laptop using WiFi:

Time:
Attachment 183298


Download Speed:
Attachment 183299


List of Files:
Attachment 183300


Total Size:
Attachment 183301


This averages to 31MiB/s for complete download, mostly because of the verification process times and new download initialization overhead. My real CAP is 41.7MiB/s and the stats on the download screen was very close to this. :)

UPDATE: On my other laptop running on 1Gbit LAN, I got same files in 1:38, actual reported DL speed was exactly the same but due to slower file verification process (I know this laptop calculates hashes a bit slower than the other one) it took a lot longer to complete the whole batch. The absolutely fastest I could get the files is about 65seconds so 83-98s is very good. :)

That's averaging slightly faster than I get, I'm usually hitting 32 - 35 MBps.

But my hardware slows me down, in that my system is the following:

Intel Core i7 Extreme 965 @ 3740.62 MHz - CPU-Z VALIDATOR

The hash checks take a bit longer. Added to that I am also downloading the combined packages for all X64 editions at once to make an AIO x64 .ISO when using UUP DUMP.

Kari said:

This is simple math. UUP Dump / Aria 2 downloader usually uses all bandwidth available, so if you have no other downloads going on and no other overhead, downloads being between 2.5 and 2.6 GB depending on language version, it will take 36 - 37 minutes on 10 Mbps connection.

On 50 Mbps (6.25 MBps) it would take just under 7 and a half minutes, on 100 Mbps (12.5 MBps) it would take just under 3 minutes 40 seconds, and so on.

Kari

Yes, that would affect the DL speed itself.

slicendice said:

UUP-Dump mini server only serves the web frontend locally, so this isn't even a comparison and has nothing to do with download speeds since it does not impact download speeds in any way. The actual downloads are simple WGET commands or similar, nothing more. So yes, only limits are you network cap and MS server upload cap for the actual download part. For the verification part, the limit is your storage drive speed, CPU speed and memory speed. All affecting the final outcome.

What affects your UUP Miniserver speeds:

1. ISP network cap
2. MS server network cap
3. Total response times between your computer and MS server
4. Your router internal performance and caps
5. Connection type and speed to router from computer
6. Storage drive speed
7. CPU speed
8. Memory speed

CPU utilization will also affect how fast it can check integrity of the files being downloaded. And The way it does it, checking each file as it is still downloading the others, to me, seems a bit slower. If I take the copy of all the SHa-1 Hashes that is at the bottom and save them to a single file, 0.sha1, in the folder where the files are downloaded, and then use Hash Check to verify, it verifies all (usually ~41 files) within seconds (but, of course, that again is a measure of the resources available - the hash check performed by the script in UUP DUMP is, IIRC, relegating a single CPU thread to the hash check, whereas my after download check runs full unthrottled).

My system is one of those anomalies - extremely fast Internet coupled with rather slow hardware (the only reason it is not any slower is that I am using SSDs on this pseudo SATA III connection that my mobo has).

My CPU still gives me fits, at times, when it comes to crunching data, though.

cereberus said:

Which is a very detailed way of saying "as fast as your broadband allows you, assuming speed is not capped at other end" .

CPI speed and storage speed will barely make any difference compared with download speeds though.

You'd be surprised. It depends upon the actual speeds available. If the speeds are so fast that the CPU cannot keep up, yiou'll see noticeable pauses when swapping from one dl to another using hte same CPU thread - I've seen it on my machine plenty of times.

slicendice said:

This completely depends on your DL cap, CPU and Storage speeds. On an older 5400rpm laptop HDD the verification process is REALLY slow.

Somewhat. Other factors are involved to a lesser degree, of course - those are probably the main factors, plus utilization of resources / availability of free resources.

slicendice said:

Just to prove this, I did a run of same files on same hardware except now on a HDD.

Time on SSD:
Attachment 183306


Time on HDD:
Attachment 183307

1 minute 38 seconds is extremely fast, and it reflects your hardware. My connection is pretty close to yours, but my hardware is woefully behind yours. Here is my test for actual DL speed:

(I selected the Feature update to Windows 10, version 1803 (17331.1) arm 64, chose English (US) language and left the editions setting at All editions, and started the timer immediately after pressing the link to start downloading:



As you can see, my speeds approached what you had (it went over 35 MBps before dropping after it started losing DL threads), but my total time taken was almost 65 seconds more than yours a direct relation to my older hardware.

If I time using the SHA-1 checksums file using Hash Check, the total time to check all 44 files is much, much faster than the the collective time spent checking the files using the UUP DUMP script:



I might get SysInternal's Affinity utility, and run the same check again forcing it to use only a single CPU (as best as I can simulate a single thread) and see how long it takes...

cereberus said:

I stand corrected but tbh your figures are decidely skewed because you have very fast broadband. For users with a more sedate download speed, the %differential will be a lot less.

Fast broadband and slow hardware already makes a difference. But fast hardware and slow broadband would be the least noticeable difference, because hte computer is literally twiddling its proverbial thumbs waiting on files to complete downloading before being able to verify anything.

My opposite situation has, more than once, had Aria 2 had 2-3 files queued for verification because the DL was so fast it got ahead of the verification.

slicendice said:

Yes, that is true. The slower the broadband speed the less impact other hardware has on total completion times.

My internet is slow, I need to upgrade it soon.

Pfft - 350+ Mbps is not fast enough? lmfao (neither for me, actually lol)

slicendice said:

The download speed is the same in WU, but it's all the other copying and integrity verification stuff that takes ages on WU.

On every release of a new build, the download part of WU has been way less than 2 minutes for me, but the total time taken to complete the online part of WU, has been about 20-40 minutes...depending on update.

Oh, almost forgot, the integrity checks on WU are single threaded, while I believe it's multi threaded in UUP-Dump (need to verify this, but at least it verifies multiple files at the same time), or just a different type of integrity check.

Then they are misrepresenting the processes collectively as downloading when it is doing more than just downloading. Mine should take no more than 2 minutes - but it routinely takes up to 15 minutes, and while I understand the need to make this happen without taxing the system resources, I wish they would offer an option to allow it to go full tilt if the user so designates so it can finish much faster.

slicendice said:

It's all about access times on SSD vs HDD. While downloading with default settings and the HDD cache buffer is full the HDD has to write to 4 different locations which means the needle has to jump to 4 different locations and once the verification process starts the needle has to jump to even more locations. This slows down everything a lot.

Best would be to download to a RAM disk on really fast hardware. :)

That would be nice. I only have 12 GB, so making a RAM disk is not in my cards - but I imaging I could shave at least 30 seconds off via UUP DUMP running all this in a RAM drive versus off my SSDs....

slicendice said:

Heheh, since the whole UUP mini server is just a bunch of source code, I'm certain it can be hacked to skip the verification. I would however not recommend this.

Yes, any type of RAM disk impacts performance a lot for any IO activity. The boost in performance is huge.

Actually, I think I might take a stab at it - as seen on my system, since they provide the SHA-1 Hashes, and it takes next to no time when the machine is not otherwise preoccupied with downloading, it would be in my best interest to DL without verification, verify all at once, and re-download any files that had issues....

Hmmm....

cereberus said:

Thinking abut it, I do not see how a RAM disk would gain me much as my download to SSD is maxed out at my max broadband speed and remains constant. I would only gain anything in the last 30 seconds or so whilst verification continues after downloads have been completed.

RAM is still on several orders of magnitude faster than even conventional SSDs. not so much faster on newer machines, but still fast enough. It should make a noticeable difference on all but the fastest machines these days, particularly on machines that are not making use of NVMe drives.

I just realized - my download size is a lot larger than most people;s because I build the AIO - so the time difference of 65 seconds is probably negligible, now that I think about it, because my total DL size is ~4.5 GB...

johngalt said:

I just realized - my download size is a lot larger than most people;s because I build the AIO - so the time difference of 65 seconds is probably negligible, now that I think about it, because my total DL size is ~4.5 GB...

Yes, your completion times should be quite close to mine, maybe even a bit faster.