The reason here is that you're using SuperServer on machines with multiple
cpu's - regardless of whether they're Logical or Physical.

If you've got multiple CPU cores, use Classic. It's the only one that
scales, and it means your application won't block all other requests while
it's doing a large query.

Most likely the above is an over-simplistic answer, but all I've ever used
over the last four years is classic, and no query/export/report has ever
blocked other people from working...

Nige.

ps. We could consider renaming the versions of Firebird:
Embedded -> Embedded
SuperServer -> SlimServer (Single processor)
Classic -> SMPServer (Multiple Processor)

> -----Original Message-----
> From: Robert martin [mailto:rob@...]
> Sent: Friday, 18 February 2005 9:07 AM
> To: firebird-support@yahoogroups.com
> Subject: Re: [firebird-support] Hyperthreading, FB 1.5/2.0, Pentium 4,
> Win2003?
>
>
>
> Hi Geoff
>
> Awesome fault report! This exactly the problem we
> experience. We set
> up a new empty database and then pump data from another
> database into it
> (TCP/IP connection), we get the pause problem. With
> hyperhtreading this
> database pump takes 20hrs+ on one clients machine. Without
> HT it takes
> about 10minutes. Our fixes are similar to Geoffs.
>
> I really hope this is fixed for FB 2. Do you know if it is
> scheduled to
> be Geoff?
>
> Rob Martin
> Software Engineer
>
> phone +64 03 377 0495
> fax +64 03 377 0496
> web www.chreos.com
>
> Wild Software Ltd
>
>
>
> Geoff Worboys wrote:
>
> >>It was my understanding that the hyperthreading issue was
> >>resolved in FB 1.5, at least that was the reason we moved
> >>to FB 1.5 in the first place and I seem to remember our
> >>testing showed that it was fixed.
> >>
> >>
> >
> >I am not not familiar with all issues that may have existed,
> >but I can confirm that at least one HT issue remains with
> >FB v1.5.2 (superserver).
> >
> >If HT is enabled and you do transfers between two databases
> >using non-local connections (eg: TCPIP either remote or
> >localhost) then the transfer seems to pause at intervals.
> >(Everything just sits there, no CPU activity, nothing). After
> >a short time (a few seconds to a minute or so) it wakes up and
> >does some more records and then pauses again.
> >
> >The problem is unpredictable. It does not effect all tables,
> >(seeming to effect mostly tables with a large number of rows),
> >it does not pause in the same places each time nor for the
> >same amount of time. In some situations it can be very severe
> >making the transfer so slow as to be impractical, in other
> >situations the pauses may be hardly noticed.
> >
> >Activity on other server connections (to the same or different
> >databases to those involved in the transfer) seems to wake-up
> >the transfer. So the problem is mostly seen during data-pump
> >situations where no other users are operating - like my DBak
> >appliciation :-(
> >
> >On single CPU systems with HT the solution is to disable HT.
> >
> >On systems with dual physical CPUs plus HT (so you see four
> >CPUs in the task manager) it is possible that disabling HT
> >will actually make the situation worse! Note that this is NOT
> >the old SMP problem, it is specific to newer CPUs with HT
> >capability. I have run FB on older SMP systems with no
> >problem (with CPU affinity of course).
> >
> >The only way to minimise the problem on dual physical CPU
> >systems seems to be to leave HT enabled and set the CPU
> >affinity to at least the two logical CPUs on the same physical
> >CPU (0 + 2 or 1 + 3). Even then the pauses seem to occur.
> >Setting the CPU affinity to all four CPUs seems to stop the
> >pauses but I have not yet worked out whether this then causes
> >the old SMP CPU-thrashing problem to occur.
> >
> >I have seen the problem myself on Win2000 Server, WinXP Pro.
> >I have heard other reports of the problem on WinXP and also
> >Win2003 server.
> >
> >I have not seen the problem occur in other situations, such as
> >normal user activity against the server, I have only ever seen
> >it during data-pump. That is not to say it does not occur,
> >only that I cannot seem to produce it in other circumstances.
> >
> >
> >
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> __________ NOD32 1.1000 (20050216) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.nod32.com
>
>