WinXP SMP still VERY SLOW under VB 4.3.6

[thanar]

I thought I'd tried VB once again with an XP guest, since I was having issues with this guest OS.
Unfortunately, when I/O/APIC is enabled (and multiple CPUs selected) on the VM and the guest OS is WinXP, there's still an awful amount of sluggishness…

On a fresh winXP sp2 install, a plain zip file uncompress took 430sec, while after switching to the "old" HAL and 8259A interrupt controller (winXP sees just one CPU), the uncompress took 350sec. The difference is much more noticeable in the way the GUI works. Parallels does it in 435sec, with APIC and 4 CPUs, no issues.

I thought that bug would have been corrected by now.

Related threads:
viewtopic.php?f=2&t=58533
viewtopic.php?f=1&t=58445

[michaln]

I thought I'd tried VB once again with an XP guest, since I was having issues with this guest OS.
Unfortunately, when I/O/APIC is enabled (and multiple CPUs selected) on the VM and the guest OS is WinXP, there's still an awful amount of sluggishness…

Surely it must have crossed your mind that maybe there is a reason why XP VMs are not configured with an I/O APIC by default with VirtualBox? Perhaps because on some host systems, I/O APIC will make XP guests slightly to significantly slower... nah, that would make too much sense.

I thought that bug would have been corrected by now.

Somehow the bug only affects people who are unable to supply any information that might help fix it. So of course it's going to stay that way.

[socratis]

I was one of the people pitching in at those two last threads that you mentioned. What I haven't done is add my voice to a bug ticket. Do you know if there is one open so I can do it?

[michaln]

I was one of the people pitching in at those two last threads that you mentioned. What I haven't done is add my voice to a bug ticket. Do you know if there is one open so I can do it?

I don't know of any ticket, but you can certainly create a new one.

What we need is a) evidence that this is a regression relative to older VBox versions, and b) a reproduction scenario. Without both of those, there's honestly no one anything will do, because we simply don't see any problem. It is possible that there's some issue affecting only specific host hardware and/or software, but that is really just a wild guess without any evidence pointing in that direction.

[socratis]

Ticket added: https://www.virtualbox.org/ticket/12536

[michaln]

Sorry, movies are a waste of bandwidth. I'm not even going to look at it because I have no idea what your host hardware/software is, how your VM is configured, and how your host is loaded. Just don't bother. A video might be useful in case of a screen corruption, but not for this. The important thing is the VBox.log file. In the case of XP guests, knowing the HAL used by the guest is also relevant.

As for the rest, pointing to forum threads is no good either. It's like this -- you want some developer to look at the problem in the hope that it will get fixed for you. I personally have zero interest in trawling through random forum posts in the hope of distilling a few nuggets of truth out of them. I doubt the other developers look at it differently. Put the facts in the ticket, if there are any facts to be had. Don't expect someone else to go on a wild goose chase. There are far too many other tickets that are a lot easier to work on.

The numbers are interesting. Without having any idea how they were obtained, they are unfortunately irrelevant. You need to provide an exact recipe how someone else can reproduce such numbers.

What's "old APIC" and "new APIC" BTW? Do you mean PIC vs. APIC?

[socratis]

You're right about the movies, but, it did provide a "look at it and it's obvious" kind of deal. Stick with the numbers if you want. They are verifiable. I tried the experiment 3 times before I posted it. It's not speculation. It's evidence.

If you're a scientist and you hear a lot of "anecdotal" evidence on a topic that you're working on, it should spur up your curiosity. It did in my case. I was not the first one to complain. I simply tried to put a lot of people's complaints in a centralized place.

The VBox log files show nothing of interest (at least to an untrained eye like mine). I will attach them to the bug report for completion in case you discover something.

You are right about "how to obtain this specific situation". I will post the VBox.log and VM info for both cases.

OldAPIC and NewAPIC is described in detail on the bug report "How to".

[thanar]

First off, a bit less arrogant and sarcastic attitude would be much more appreciated from a developer, michaln. This issue has been around ever since I tried vb 4.3.2, it wasn't there under 4.2.x afaik.

I (and lots of others) have posted reproduction scenarios many times; I don't really get i twhy it would be so much better to send logs and add trac records, when it is so easy to reproduce:
1. Create a new VM using With multiple processors
2. Install winXP from scratch (it's sp2 Greek in my case)
3. Grab a zip file and expand it (it's a self-extracting on a LAN server in my case) and time the time needed
4. Change "APCI Multiprocessor PC" in Computer's device manager to "Advanced Power and Configuration Interface (ACPI) PC" manually
5. Expand again, it should be around 30% faster.

I will try to elaborate on the bug report socratis posted later on.

[socratis]

Correction
It is not APIC, it's ACPI. (damned sydlexia ). Sorry for the confusion. It's APIC that's causing it, it's ACPI that "fixes" it.

The "new" and "old" come from the Computer property in the Device Manager

ACPI.png (6.43 KiB) Viewed 8216 times

newACPI = ACPI Multiprocessor PC
oldACPI = Advanced Configuration and Power Interface (ACPI) PC

Now, attached are the VBox_newACPI.txt, VBox_oldACPI.txt and VMInfo.txt as ACPI.zip.

@moderators
I'm not sure if I should be posting the attachments here, in the bug report or both. This time I'll do it in both just to be safe, but an advice for the appropriate action is appreciated. Same question for the discussion. Should we continue the discussion in this thread and have a link at the bug report that points here? I'll do it for the moment, but again, please advice.

[noteirak]

I think michaln fails to make his thoughts come across, and I will, for once, expand on this topic to show you why you fail to meet his requirements, from a programmer point of view :

1. Create a new VM using With multiple processors

How many? First piece of info missing. Do you over-comming your physical cores?
What about the rest of the VM config? how much RAM? Do you overcommit it? What about the Virtualization features? etc.

2. Install winXP from scratch (it's sp2 Greek in my case)

I don't think Greek is the most easy media to come across. Also SP2. It would be a bit hard to devs to reproduce this exactly if they don't have access to the install medium per example. What about a MSDN ISO name with a MD5 checksum? That would make it easier to find or at least verify this is the same one.

3. Grab a zip file and expand it (it's a self-extracting on a LAN server in my case) and time the time needed

"a zip" what size? What is the compressiong level? How was it compress in the first place? What does it contain?
You talk about self-extracting, but you don't tell how it was created.
You could find something more universal to reproduce this per example. The devs don't have access to "a zip".

4. Change "APCI Multiprocessor PC" in Computer's device manager to "Advanced Power and Configuration Interface (ACPI) PC" manually

So you change something in the Guest OS, but not in the Virtualbox config. So you assume this is a Virtualbox bug when the config is unchanged, but the guest OS is.
It would like using a car, saying it's not giving you the expected 200 horse power, and then say "oh but if I change the way to press the accelerator, it works!" and expect the card maker to make it adapt by magic to your driving style.

5. Expand again, it should be around 30% faster.

Did you reboot meawhile? something? "around" is not really an accurate time value. Also, what makes you think this is not I/O cache related? You just used the file you used 2 sec ago...

And finally

I (and lots of others) have posted reproduction scenarios many times

None of them is precise enough, that is the problem. You assume many things in these scenarios.

I don't really get i twhy it would be so much better to send logs and add trac records

Because the logs give you facts about the hardware and your setup. They give a full list of CPU features per example. What if the bug is common to only some CPUs with that feature? How could you know it without the log?
The CPU feature issue is actually related to a very recent bug (TRIPLE FAULT) that was solved on AMD's.

when it is so easy to reproduce

Of course it is for you, since you have it in front of yourself. But people don't have your exact hardware, and usage history. They do their best to try to reproduce, but I can assure you this is simply not enough. You need facts and info. A lot of them.


I hope I made it clear by going point by point through the post how little relevant info was given. Let this be a clear example of what level of info is not enough.

[socratis]

OK, I'll give you then some hard info then. Two fresh WinXP installations (today's catch). Things that changed from the default template: 512 MB RAM, no Floppy. One of them has IO/APIC enabled, the other doesn't. The difference in the naming and the results; one of them contains a "w" (the one with the IO/APIC) and the other contains a "wo" (the one without the IO/APIC). VMs start and run in parallel with the command:

VBoxManage startvm XPwoIOAPIC ; VBoxManage startvm XPwIOAPIC

No SP, no GAs. As clean as they come. Boot times until the fat lady sings...
w/o IO/APIC : Boot 10 sec.
w IO/APIC(1): Boot 10 sec.

With GAs installed (no 3D) I get the same results as above. If I change the number of processors for XPwithIOAPIC to 2, Windows finds new hardware and asks for a restart. After that, If you go into Control Panel -> System > Hardware -> Device Manager -> Computer:
w/o IO/APIC : Advanced Configuration and Power Interface (ACPI) PC
w IO/APIC(2): ACPI Multiprocessor PC

Boot times with 2 processors in the IO/APIC enabled VM:
w/o IO/APIC : Boot 10 sec.
w IO/APIC(2): Boot 18 sec.

VBox logs are attached. I have not upgraded to SP3 just in case you want me to run some other tests while they're virgin.

Edit: I forgot to mention the host info: OSX 10.6.8, 16 GB RAM, 4 physical CPUs i7

[socratis]

Just for kicks, I took some boot up time measurements, for the machine with the IO/APIC enabled and different number of CPUs. All measurements were done after a 2nd boot of the guest to avoid I/O cache issues. Units are in seconds.
1 CPU: 17
2 CPUs: 18
3 CPUs: 21
4 CPUs: 22 <- Number of physical cores on my machine
5 CPUs: 23
6 CPUs: 25
7 CPUs: 26
8 CPUs: 27 <- Number of logical cores on my machine
9 CPUs: 30
10 CPUs: 40
...
16 CPUs: <- Max. number of CPUs that VBox will allow. Too painful to start. Aborted at the 4 minute mark with 100% CPU at the host...

I have the VBox logs, but I don't think they add anything to the picture. BTW, I was expecting to see a performance hit, simply not that much. Remember, without IO/APIC enabled and 1 CPU the boot time on my system is 10 sec. Simply enabling IO/APIC results in a penalty of ~70% at boot time...

[thanar]

socratis,
Wonderfully done! I hope all that information will help the developers. Does the version of winXP you're using show up in the logs?

noteirak,
I really think all this information is not needed for the bug to reproduce. If you told me that you DID try on winXP (an lang., any sp) and it doesn't show up (that would take around 30mins of your time), I would be more than happy to provide the extra information.

[socratis]

Not sure, but it's plain XP3, not even SP1 or any other update installed. I highly doubt that it makes a difference. My normal XP VM is on SP3 with the latest and greatest updates and its boot time is around 23 secs with 4 CPUs or 17 sec with 1 CPU, verifying the previously posted results.

Next up; number crunching...

[michaln]

It is not APIC, it's ACPI. (damned sydlexia ). Sorry for the confusion. It's APIC that's causing it, it's ACPI that "fixes" it.

I'm lost... how does ACPI fix it?

The "new" and "old" come from the Computer property in the Device Manager

ACPI.png

newACPI = ACPI Multiprocessor PC
oldACPI = Advanced Configuration and Power Interface (ACPI) PC

So ACPI is used in both cases. APIC is used in the multiprocessor case but not the other one.

Yes, the acronyms are bloody confusing and I wish they didn't look so similar...

I'm not sure if I should be posting the attachments here, in the bug report or both. This time I'll do it in both just to be safe, but an advice for the appropriate action is appreciated

If you're reporting a bug, attach all relevant information to the ticket. Log files definitely count as relevant.