Hi Greg and others, Am 03.08.2020 um 21:31 schrieb Greg Troxel:
Other than the 1 cpu vs ? cpus, no. I tested xen perfmorance long ago, in 2006 with a setupNetBSD dom0 disk file in filesystem NetBSD domU with xbd0 from the file and found that reading with dd: the dom0 raw disk was just about the same as bare metal the file was maybe 5-10% slower (maybe not quite; it was noticeable but not a big deal) the xbd0d "raw disk" was also 5-10 % slower than reading the file in the dom0 Now, this isn't what you asked, but I find the difference you found seem like a bug. I would definitely do dd from the raw disk in your case 1 and 2, followed by dd of the iso. Also, I would repeat your tests and run "systat vmstat" during each case, and also netstat to see if the network interface is not keeping up. Then I would run iperf, ttcp or whatever to test network separate from samba and disk.
many thanks to you for the helpful hints. First of all it was important for me to get feedback if the performance losses I noticed are common. As I understood it, this is rather not the case and a detailed investigation is appropriate. This is what I will tackle next.
By the way, I noticed just today that even when using the "pure" NetBSD kernel without Xen the performance is also bad in some cases. The ISO file mentioned in the last posting is written with about 60 MByte/s. Even if I trigger a sync every second the performance hardly drops. However - if I (after a reboot to clean up the file cache) want to copy the same file back via the same way (from NetBSD point of view "read") I also only get a throughput of about 20 MByte/s. I thought that reading should be faster than writing in any case.
But there is one detail I have just now become aware of... when I bought these NUCs a few years ago, I installed hybrid hard disks (Seagate Firecuda SSHD 2TB). This type has a mechanical/magnetic mass storage and a (relatively small) SSD on the side. But from the point of view of the operating system the device appears as a whole. The on-disk-controller decides when and how the SSD is used. I don't know this in detail either, only that booting from this disk works quite fast. It's quite possible that here simply the blocks that are read first after power on are moved to the SSD. To cut a long story short - I think I first have to convert to either a purely mechanical hard disk or a pure SSD to avoid measurement inaccuracies due to the unpredictable behavior of the SSHD. Then I will approach the whole thing scientifically and consider your advice.
This week will be very exhausting and I can't assure that I will progress quickly. But I will stay on it and write my results here as soon as I have them.
Best regards Matthias
