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 setup
NetBSD 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