|
PureBytes Links
Trading Reference Links
|
I'm not a tech and I don't even use TS2K, but I think
the file size is reduced because morning update reduces
the amount of data TS accesses, but it doesn't delete
the data from the HD. So if TS is set to "save" 100
days of intraday data, and you've been running TS for
2 years (500 trading days), the exported file will be
400 days lighter and tighter for that symbol.
BW
>From: Craig <craigbud@xxxxxxxxxxx>
>To: BobR <bobrabcd@xxxxxxxxxxxxx>, Fred <srqblue@xxxxxxxx>,
>omega-list@xxxxxxxxxx
>Subject: Re: DTN data changes & GS patch
>Date: Sun, 13 Jan 2002 13:33:17 -0800
>
>Here's one explanation: If you remove a field from the GS for some or all
>of your markets, the GS will not erase that data, but removes the reference
>to that data. If you later want that field back, the GS must create the
>data from scratch. For example, if you remove the 1-minute field and then
>later want it back, the GS has to build a new set of 1-minute data from
>your ticks. Now you have two sets of 1-minute data in your PDS, but the GS
>only has reference to the new one.
>
>
>At 12:19 PM 1/13/2002 -0800, BobR wrote:
>>Apparantly the copy out of data, change pds to oldpds and reimport to
>>create
>>new pds reduces the size of the pds considerably. By 50% in my case.
>>When
>>the data is exported as .xpo it is compressed and then when reimported the
>>decompressed data must take up less space. Wonder if there are any
>>operational efficiency benefits besides space saving after doing this?
>>
>>bobr
>>
>>----- Original Message -----
>>From: "Fred" <srqblue@xxxxxxxx>
>>To: <omega-list@xxxxxxxxxx>
>>Sent: Sunday, January 13, 2002 10:12 AM
>>Subject: DTN data changes & GS patch
>>
>>
>> >
>> > The changes that DTN informs me were to take place on Saturday Jan
>> > 13th were the addition of:
>> > 1) Fundamental data fields, such as market cap etc.
>> > 2) Last sequence number.
>> >
>> > Very definitely they are NOT adding incremental futures volume, the
>> > change that caused the CPU overload we are all familiar with.
>> >
>> > The fundamental data fields I understood were not to be updated every
>> > tick--which makes a great deal of sense.
>> >
>> > The registry changes sounds like it is designed more for the CPU
>> > overload problem from incremental futures volume than the last
>> > sequence number addition.
>> >
>> > What problem do we actually know the patch and registry change will
>> > accommodate? I have re booted the DTN receiver and re-booted my GS
>> > but have made no changes in the registry and have no possession of
>> > the disappearing patch to implement. Since I am also getting ticks
>> > received and ticks processed on the GS this Sunday afternoon I believe
>> > I am also ready for Monday. Just to be safe, I took the sledgehammer
>> > approach and backed up my entire server directory because it only took
>> > a couple of mouse clicks and 10 minutes, rather than the lengthly
>> > sounding copy in and copy out of xpo file(s).
>> >
>> > I will watch this space this evening when the futures start up and
>> > Monday morning to see how we all do.
>> >
>> >
>> > "Success is the only test of genius" -R.Adm Daniel Gallery 1901-1977
>> >
>
>
|