Closed Pulsera closed 1 year ago
pbatard
commented
6 years ago Yeah, I've been having some plans to update the speed comparison, but it's just not a high priority.
Also, even though the application changed here and there, internally, the ISO → USB extraction has hardly been altered in a way that should affect the speed.
I'm going to keep that issue, but flag it as deferred.
pbatard
commented
6 years ago PS: I have updated the Windows 7 USB download tool link on the homepage to point to the official Microsoft information page (which may redirect to codeplex archive for the download link, but that's entirely Microsoft's issue, as the goal from my link is to provide a description of what the tool does, not a download link).
As to unebootin, I don't think I'm going to bother about the github.io redirect for now, as it seems, with Microsoft's purchase of github, a few projects are migrating back to SourceForge. The last thing I'd want would be to update the link and find that unetbooting are back to SF. As long as the SF redirection works and is instantaneous, I don't see an issue.
shwegyi198361
commented
4 years ago Yeah, I've been having some plans to update the speed comparison, but it's just not a high priority.
Also, even though the application changed here and there, internally, the ISO → USB extraction has hardly been altered in a way that should affect the speed.
I'm going to keep that issue, but flag it as deferred.
shwegyi198361
commented
4 years ago Checklist
- [x] I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
- [x] I performed a search in the issue tracker for similar issues, using keywords relevant to my problem.
The speed comparison in your website and the README file are completely outdated. It would be a good idea considering Rufus had major changes since v1.1.0, that was 6 years ago. Also the UNetbootin link redirects to the new official link, which is https://unetbootin.github.io/ and the versioning for their program appears to be different. Latest one is 661. According to properties the software is still v1.1.1.1 but for some reason they never changed that. Also the windows link, loads the microsoft website, which tells you to download from codeplex, which redirects you to archive.codeplex which tells you the project is on a microsoft link. It would be better to just link the file download than going through several links.
- Test new Rufus release (v3.0)
- Update UNetbootin link with the newer one. https://unetbootin.github.io
- Test newer release of UNetbootin (661)
- Update Windows link. https://www.microsoft.com/en-us/download/details.aspx?id=56485
- Test with Windows 10, Ubuntu 18.04, and any other OS that seems relevant (Maybe BSD one)
oam7575
commented
2 years ago Hello All.
I have carried out some benchmarking of Rufus 3.20.1929 vs newer versions of several (somewhat) comparable applications. To make testing faster and remove as many bottlenecks as possible source drive was internal NVMe SSD target drive was USB 3.0 SSD.
Details and expanded notes are below.
Crystal Diskmark shows about 250Mbytes per second for the USB SSD
Final note, I am aware of Ventoy which essentially uses a copy / paste of a complete ISO to create a multi boot drive. I used a batch script to time a dos / cmd level file copy operation for some of the ISO's listed above. The batch script was taken from here : https://stackoverflow.com/questions/673523/how-do-i-measure-execution-time-of-a-command-on-the-windows-command-line#
Results
timecmd.bat copy Win11_English_x64.iso i:\ 1 file(s) copied. command took 0:0:24.34 (24.34s total)
timecmd.bat copy slackware64-15.0-install-dvd.iso i:\ 1 file(s) copied. command took 0:0:16.69 (16.69s total)
timecmd.bat copy ubuntu-22.04.1-desktop-amd64.iso i:\ 1 file(s) copied. command took 0:0:16.83 (16.83s total)
pbatard
commented
2 years ago Thanks for this extensive report.
I'm happy to see that Rufus is killing it for DD mode, which demonstrates that the changes we applied in a0904cad354fb1d97fb1313b598beeb4b038fc6c were worth it.
And those changes is pretty much the reason why we haven't published updated results, because we are planning to apply similar speed improvements for ISO mode, which we know have been lacking a bit. Oh, and for the record (at least this is something I've seen for the MD5/SHA checksum computations) I do believe that Rufus is probably also penalized by the fact that, unless you're running the Windows Store version, you're going to be running a 32-bit application and that is going to add some overhead for I/O, whereas utilities like UUI are going to use the 64-bit version of 7-zip for extraction, which does help (though, regardless of whether you're using the 32 or 64-bit version, 7-zip on its own, is already pretty much the best in class for data extraction speed).
All this too say that we're well aware that there is room for improvement, which we're planning to accomplish by switching ISO I/O to async mode (item 2 on #1646), just like we did switch DD I/O to async mode with the good results the benchmarks above have shown. However, this will take some time and some planning, which is evidenced by the fact that we've been planning on carrying this out for a few years now, and still haven't managed to allocate the time to do so.
And that is the precise reason why, until we have integrated these planned I/O changes, we're not going to update the speed comparison reports, because we don't consider that these results will be representative of where Rufus will be once our I/O has been finalized.
Finally, just a small nitpick: I don't think splitting minutes and seconds in a table is for the best, as it makes it harder to get the full picture at a glance. I think those times would be better to reside in a single column alone, either as a mm:ss value or just a sss.
But once again, thanks a lot for spending time on this!
pbatard
commented
1 year ago I'm going to close this issue, on account that I have now removed the speed comparison from the homepage due to the fact that it's become mostly pointless when most people will be comparing Rufus with Ventoy, and we're never going to be "best" Ventoy since we're extracting ISO content rather than copying it wholesale. In other words, because any comprehensive speed comparison table now implies comparing apples with oranges, there's just no point in trying to provide one.
I am still very much planning to apply the double buffering changes to ISO file extraction when I get the chance, and of course apply any changes that can improve Rufus write speeds, but I think the speed comparison has run its course...
github-actions[bot]
commented
1 year ago This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.
Checklist
[x] I performed a search in the issue tracker for similar issues, using keywords relevant to my problem.
The speed comparison in your website and the README file are completely outdated. It would be a good idea considering Rufus had major changes since v1.1.0, that was 6 years ago. Also the UNetbootin link redirects to the new official link, which is https://unetbootin.github.io/ and the versioning for their program appears to be different. Latest one is 661. According to properties the software is still v1.1.1.1 but for some reason they never changed that. Also the windows link, loads the microsoft website, which tells you to download from codeplex, which redirects you to archive.codeplex which tells you the project is on a microsoft link. It would be better to just link the file download than going through several links.