Pokertracker load time

[astroglide]

[ QUOTE ]
during this recording time, they aren't writing constantly to disk, they are filling a RAM buffer, then writing that buffer to disk as they fill a second buffer, then writing that to disk

[/ QUOTE ]

according to what i'm reading best quality (which is always used for the 30 second buffer) is about 3.5gb/hr. the tivo only has 32mb of ram, some of which is obviously in use by the os/tivo apps. the buffer is always running. storing of preferences, what aspects of the show were fast forwarded, etc haven't even been brought up. now how often do you think it's writing? enough to qualify as "constantly"?

[ QUOTE ]
they don't ignore the defrag button because ext2 is used

[/ QUOTE ]

yes they do. when was the last time you ever saw or heard of somebody defragging an ext2 filesystem?

[ QUOTE ]
note: you can use ext2 on a desktop system

[/ QUOTE ]

99.99% of the people here, discussing pokertracker, are obviously running windows.

[ QUOTE ]
you can't say they dont' work like a desktop pc... THEY ARE A DESKTOP PC!

[/ QUOTE ]

it's a purpose-built appliance that happens to use some components that are also used in desktop pcs. it is not used like a desktop and should not be compared to one.

[ QUOTE ]
they run on the same chipsets... use the same hardware...

[/ QUOTE ]

they use powerpc cpus. most people would classify that as a mac. seen any macs with intel-compatible chipsets lately?

[edrugtrader]

are you saying 50% of the graph you have posted is white? the color key said white = free space.

if you are saying 50% of the graph is white, THEN you are 100% right... if only that was the case. looks more like 10% to me... and the 90% that is full is mainly 700MB ISO files.

buddy. you are wrong.

[astroglide]

are you actually trying to argue that the hard drive isn't more than half empty? it is. look at the analysis log i posted, it says free space is 54%. don't believe it? click here for the drive's property page and click here for the entire window (complete with explicit recommendation to defrag).

[BradleyT]

[ QUOTE ]
i wrote my own poker tracker before there was a poker tracker. i had my server pull EVERY hand history (not just ones from my table) from an online site and store them in my own database. i have 1.2 million hands stored for 15k players. my database (running mysql) was around 150 MB, and my client provided all the same stats near instantly. this was all running on a 533P3 with 128MB of ram. this was a dedicated machine just for this program and the webserver and database.

[/ QUOTE ]

LOL yeah sure. I suppose this only took an hour or two to develop. Oh and I'm sure that the poker sites would be glad to send out 1.2 million HH emails to one single person.

So let's see a sample table structure for two of your larger tables that you set up for your "poker tracker".

[nykenny]

[ QUOTE ]
hard drive speed should make a material difference too. i've got a 2.8ghz p4, a 10k raptor hard drive, and 1gb of ram

[/ QUOTE ]

that's a pretty good setup, i think i need to upgrade soon too...

[nykenny]

[ QUOTE ]
dang, i guess i need to defrag, even when I compact it doesnt really help. My computer is 4 yrs old though, only 733 MHZ, maybe its just old, its tough for it to run 3 monitors and all the games I've got going.

[/ QUOTE ]

i honestly thought i was the ONLY one running on 3 monitors ... guess i am not the only 10-tabler either... [img]/images/graemlins/frown.gif[/img]

[nykenny]

[ QUOTE ]
on current operating systems and file systems (NOT hardware), this problem is vastly reduced. the files are organized better on the disk so they'll be room for new files... kind of think of it as defrag on the fly. add on top of that higher capacity hard drives that are usually more than 50% empty and there is barely ever a need to defrag.

[/ QUOTE ]

don't quit your day job - poker. [img]/images/graemlins/wink.gif[/img]

as you delete and create new files, you HDD will be fragmented. de-frag is always good (at least today).

[nykenny]

[ QUOTE ]
having 1GB matters especially when running VMs, but it also allows me to disable my paging file entirely with no ill effects (which reduces HDD seeking).

[/ QUOTE ]

i have done the same for a long time now, except i don't have 1GB, but it still works better than swapping. when you are in 3 playable hands and burning a DVD, and swapping happens, the repaint of the tables can sometimes take up 2 minutes! that alone can time you out yet not qualify u to the all-in protection!

astro, good advice.

[nykenny]

[ QUOTE ]
[ QUOTE ]
Anyone in IT should know you can get the specs from the control panel.

[/ QUOTE ]
hmmm... and what is the first thing you would disable on a public terminal?

[censored] idiots.

and i wasn't a microsoft tech at the company... i maintained the unix/solaris servers and wrote intranet applications. needless to say, the "control panel" wasn't an everyday part of my job.

have fun with your MCSE and 40k bullshit grinder job though... i'm sure you'll enjoy it.

[/ QUOTE ]

40K??? whoever still makes 40K anymore????

[Richard Berg]

Guys, NTFS fragmentation is more complex than either of you are willing to admit.

It's much smarter about preventing fragmentation than FAT32 was, e.g. by preallocating space for MFT expansion, using alternate data streams for attribute changes, etc. However, the main reason that fragmentation is less of a concern is because of its structure -- the MFT descriptor stores a complete list of its physical cluster extents so that you don't have to seek through the broken chains like a memory-bound linked list. (Technically the virtual cluster numbers don't need to be stored in the MFT itself, but even very long files won't need more than 1 extra level of indirection.) In English, that means the access times for random I/O within a file don't depend nearly as much on fragmentation, especially with a modern 8MB cache disk.

Underneath, though, NTFS still uses clusters like everyone else (academics playing with LBFS's nonwithstanding). Frequent disk writes on a drive at 50% capacity could easily cause fragmentation. Why shouldn't it? So long as you have the VCNs cached, it's faster to do short seeks (since most desktop I/O is psuedorandom anyway) than to spread the layout over the whole platter surface just to combat one small factor of an intelligent FS's performance.

I'm happy to discuss OS internals anytime. I just don't think most people reading a Texas Hold'em forum care, which is why my first recommendation was the best answer at the time: don't defrag every night. If you really are experiencing performance-degrading fragmentation more often than a couple times a year, you can always defrag the files that need large sequential I/O individually. More likely, though, they need to be on their own partition (better: their own drive) anyway. This usually applies to things like A/V capture; database sets that don't fit in RAM are rarely read sequentially. (First person to claim it applies to pagefiles gets shot...)