|
PureBytes Links
Trading Reference Links
|
I checked this file and it was 38MB. It was loaded with I/O errors that occurred
during off market hours since Nov. 11, 1999 and Dec. 24, 1999. I leave this
system up all the time. I guess they are due to DTN resetting the box. I didn't
see any buffer overrun errors.
TS2k SP4 is on a 233MHz pentium I, 384MB RAM, 16GB wide-SCSI, and Pacific Comm
serial port and DTN box set at 460800 and NT4 SP6. TS2k is collecting data for
15,845 symbols and charting about 10 workspaces with several
symbols/indicators/systems in each.
The buffer overrun errors are probably due to the EIDE. Most decent SCSI cards
have some kind of RISC processor on them that multitasks I/O requests and SCSI
devices, does DMA transfers which all off load the main CPU of I/O.
William R Wood wrote:
> TS2k/DTN users might want to check the interesting file in Omega
> Research\Server\DTN\log.txt. This log file reports I/O and other errors
> having to do with Global Server data handling. Log.txt had grown to 16mb by
> the time I noticed it. [You can delete it periodically if it gets too big;
> it rebuilds automatically.] My log.txt is filled with thousands of error
> messages about buffer overruns and lost data. Apparently GS does not handle
> data coming out of the serial port buffer very well and thus ticks are
> dropped. I have had many contacts with Omega about dropped ticks and the
> existence of this file was never revealed to me. Now I see why; it
> demonstrates data loss between the serial port and GS which cannot be blamed
> on DTN.
>
> I run Ts2k SP4 on a PII450, 256mb, NT4 SP6, EIDE hard drive computer with
> the Pacific Commware high speed serial card set to 460,800kbps. This card
> has the 16750 UART which has the largest data buffers available. Another
> list member and DTN user has a dual processor machine with PII450's, 256mb
> NT4 SP6, SCSI hard drive and the same high speed serial card. He does not
> get these buffer overruns unless he is also using software in addition to
> Ts2k and thus stressing I/O even more. We cannot explain this discrepancy
> in performance between our 2 systems. Maybe the dual processors help. I
> don't know.
>
> A long term solution to dropped ticks is a switch from the serial port to
> the Ethernet port on the DTN D8000 receiver. The Ethernet port will provide
> 200 times the bandwidth of the serial port. DTN is in the process of
> implementing this change now. To date Omega has not expressed any
> willingness to support an Ethernet connection.
>
> Omega admits to the same buffer overrun messages on in-house DTN computers.
> Do other DTN users have buffer overrun error messages in log.txt and is any
> solution known.
>
> Bill Wood
|