Forum Discussion

ADyer's avatar
ADyer
New Contributor
15 years ago

[Resolved] Delay is taking much longer than expected

I am using soapUI Prop 3.6. I just ran a Delay(150000) command. I was expecting a delay of 2 and a half minutes, but it took 5 mins and 35 seconds. I was running this test by double clicking a test case and clicking the Start arrow from the new window. In the TestCase Log, I get the message: Step 4 [Delay 2.5 min] OK: took 150003 ms. The program thinks it took the correct amount of time, but for some reason it is taking much longer. Thanks for the help.

7 Replies

  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    Icon for Alumni rankAlumni
    15 years ago
    Hi!

    could you try this with the nightly build of 3.6.2? We made some fixes to this and I couldn't reproduce it..

    regards!

    /Ole
    eviware.com
  • ADyer's avatar
    ADyer
    New Contributor
    15 years ago
    Thank you for the response. 3.6.2 did not fix the problem unfortunately. I did some testing on the issue to help track down the problem. First off, I tested on a different machine using the same project, and the delay worked correctly on this machine. The machines are both Windows XP. The failing computer was running the project from a network drive for back up purposes, and the passing computer was running from a local copy. I created a new local project on the failing machine with just a delay test step, and the extra time was still observed. The actual time taken seems to vary though. This run took over 6 minutes for example. The failing computer has a faster processor than the other machine, so I would not think it is a performance issue. The CPU usage never goes over 5%. I also tried reinstalling the software and rebooting the machine, but I did not have any success with this either.
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    Icon for Alumni rankAlumni
    15 years ago
    Hi!

    ok.. I've changed the internal timings of the delay step a bit, this will be in the upcoming nightly build.. can you give that a go and let us know if you see any changes?

    regards!

    /Ole
    eviware.com
  • ADyer's avatar
    ADyer
    New Contributor
    15 years ago
    That worked! Thank you very much for the update. I tested on both machines and the delay is correct. I did notice one interesting side effect. The TestCase Log on the previously failing machine now says that the 150000 ms delay took 56931 ms. I am not concerned about that one personally, but thought you might wish to know about it.
  • ADyer's avatar
    ADyer
    New Contributor
    15 years ago
    We actually ran into this problem with our software. We were using a Diagnostic Stopwatch timer that was supposed to elapse in 20 seconds, but on my machine it was taking 2-3 times longer to trigger. One of our developers looked into it and was planning on just changing the type of timer used. I went to the Dell website though and updated my BIOS, and the problem was fixed. It also fixed the problem I mentioned at the end of this post where the actual delay was correct, but the report at the bottom said it took less than half the time it was supposed to. There is a note on the MSDN page for the Stopwatch class:

    http://msdn.microsoft.com/en-us/library ... watch.aspx
    "Note
    On a multiprocessor computer, it does not matter which processor the thread runs on. However, because of bugs in the BIOS or the Hardware Abstraction Layer (HAL), you can get different timing results on different processors. To specify processor affinity for a thread, use the ProcessThread.ProcessorAffinity method."

    Thought I would let you guys know since it seems like it may have been the same problem I was having with SoapUI and our software. Thanks for the nightly update fix earlier as well.