The Acme machine is pretty old, I've heard a few people say it's a R1 build, which seems to mean a P4 rather than a Celeron - they apparently switched to cheaper CPUs when they realized they could make the switch and still have everything run.

Also, the video specs are commonly reported as 64 MB of system memory being set aside for an integrated chipset to use - regardless of the total memory present, that's sucking up a lot of memory bandwidth on a board that runs a PC3200 stick.  Having an actual video card is going to do a lot for machine performance.

FYI: Mine is a Celeron and an R1 build.

Strange that the information out there is inaccurate in such a specific case, but R1 cabinets seem to be rare amongst the ITG hacking community, so it's likely that they just don't know what they're talking about.

EDIT: Forgot to mention that I added a relatively small pack - Gay4Gimmix Again - last night.  It's listed as Gimmix Again for appropriateness.  The charts are fun and generally in the 9-11 range, most have some strange gimmicks.  Rainbow-whatever-the-title-is is obscenely hard to figure out how to read, though, so I'd recommend hunting down the pack and seeing how it works first.

It's Welcome To Rainbow.  And yeah, watch it on Youtube first. 

What's inappropriate about "Gay4Gimmix"? for real

Seattle is extremely politically correct, and as much as that's gay as hell, we'd rather not deal with somebody getting all huffy about how the word "gay" was used on a pack on the machine. 

Personally, I think political correctness is pretty gay. 

I don't think anyone here really goes out of their way to be politically correct, but I do feel a need to exercise caution with regard to the ITG machine, unfortunately.  It's hard to say how much they would or wouldn't care if "potentially offensive" content was brought to their attention, but ultimately, I'd rather preempt them by keeping the machine relatively clean rather than risk them jumping straight to requesting removal of the machine.

As for the new computer:
- I wasn't paying attention when I bought the parts, so I have three DDR3 1GB sticks and a board with only two slots.  2GB of DDR3 was my original plan anyway and will still severely outperform the old setup (especially given the onboard graphics unit stealing some RAM and memory bandwidth).  I doubt that menu lag is tied to total memory so much as bandwidth (memory or disk - both will be much faster now) or a blocking I/O thread (mitigated by the dual core processor and faster everything else), so only having 2GB RAM is probably not going to slow anything down from the 3GB I thought we would have.
- I built the computer on Thursday and installed Ubuntu 10.04 on Saturday.  I'll keep working on it as I have time this week.
- The new computer runs almost silently most of the time and gives off very little heat.  OpenITG will make the CPU heat up a bit more than an idle OS post-install, but overall, the new system should use a lot less power than the old; nothing to get too excited about, but it may keep the air around the machine a degree cooler on a warm day.

Thanks for keeping the content G rated.  We know it could be a big issue if offensive lyrics are playing.  Sounds like the project is coming along well.  :-)

Posting from the new ITG computer, since I can.

I'm looking into the best ways to tune an Ubuntu system for performance, because I'm pretty sure I can get this thing to fully boot (including loading OpenITG) in around 15 seconds if I set it up right.

Tony,
If you are using the new ITG computer at home on the internet, please make sure none of those porn sites you frequent have any chance of popping up randomly once this computer is in the ITG at Acme. 
Hehehehehehe

HAHahahahahaha!

Bill, if I new how to give rep, you would totally have a +1 from me!

I'd die laughing if stuff from /b/ flashed up on the screen.

Warning: Sweet Donuts (from Gimmix Again) can crash the machine.  Hasn't happened to me personally - and I've played it a half dozen times - but I've heard of at least two people having it happen to them.  The machine will be fine once rebooted.  If you want to play it, it's safest to reboot the machine beforehand.

It seems like it's more likely to happen when the machine hasn't been rebooted in awhile and the OS becomes unresponsive afterward (meaning it's not just OpenITG having problems), so I'm going to say it's somehow tied to system resources rather than an error in the file itself, in which case the fix is a new computer.

Speaking of which, the new computer is still coming along.  I'm currently trying to hunt down and remove non-essential programs so that I can fit as much as possible on the (very fast) SSD alongside the OS without forcing the system to run only via command line.  It's not that the second drive is slow or anything, it's just that the SSD is faster.  It'll be configured to skip booting the graphical interface for efficiency's sake once installed into the machine, but I still want access to the graphical interface if I ever need to do any significant debugging.  I'm hoping to have it ready for a live test sometime soon, but I don't have a firm schedule - I can't promise it'll be ready by the 16th for a post tournament install, but it's still a possibility.

I've now copied most of the old computer's data, though it's not all loaded onto the new computer yet.  Interesting tidbit for the community: Acme's Stats.xml (which tracks high scores, among many, many other things) is almost 25 MB has data for over 2500 songs (there have been about 1300 on the machine to date, so that's another 1200 distinct USB songs - I believe a USB song must be played once to get an entry in the stats file and the same exact file is treated separately if the folder structure on your drive is different, so it's probably more like 1000 unique USB songs that have been brought in and played to date).  That said, we definitely should not be losing scores with the new install.  I will see what I can do to trim the USB entries and cut down on the file size, since that will help speed up the save sequence at the end of each set (editing the file outside of OpenITG means figuring out how to forge a machine signature, otherwise OpenITG will ignore it and start over with a blank file).

I'm also working on enhancing the Chromatic theme for the new computer - the differences will be mostly invisible on the surface.  The main changes are setting up ITG3 as the fallback template (to allow some new features from the ITG3 theme to persist into Chromatic, most importantly the OpenITG segment of the operator menu, but also an extra modifier or two) and some minor tweaks (adding a few extra text colors to the song wheel, updating the main logo to ITG3, etc) and some minor fixes (making "Fantastic" not shift by a pixel at random [okay, technically not at random, but the polling rate is bad enough that the icon doesn't shift consistently based on your actual timing, so it's useless to the player]).

Dealing with some very weird bugs (basically, I have OpenITG on the computer, but I get file not found errors when I tried to run them from the command line, which makes no sense, since the command line properly autocompletes the filename - trying to run it through the graphical shell makes a loading icon show up for a second, then nothing), not likely to have the new computer ready to install on Saturday.  I'll see what I can do to get it running in time, but this error doesn't even make sense in the first place.

I reloaded the foonmix subset pack onto the Acme machine, since it used to be there and was only removed because the old drive ran out of space.

I really would like to see some easier charts for some songs eventually (though I think the new PC is highest priority at this point).  Not just to make it more accessible for new players, but there are some charts where I want to play the song but the only chart is a 13+.

To address the H1N1 songpack (currently on the ITG machine) as an example..
A portion of its songs are also on the Tachyon Alpha songpack (link), however I'd recommend uploading Tachyon Alpha pack because those charts have the full list of difficulties from easy to expert.

Haven't gotten the chance to browse through Tachyon Beta & Gamma which I noted to be on Codx's machine, but I'd assume there are some nice charts on there as well.

I'm not sure whether or not this will be an issue with the new computer, but as a heads-up, with the current hardware, coins don't get recognized when the machine is in a certain state.  It seems to be when the game is transitioning from the title screen to the demo; I've had three quarters eaten because of this, two today, and both times were during said transition.  For obvious reasons I don't want to try to duplicate this bug anymore.

I'm almost definite that's an issue with the software on both OpenITG and the original game. It happens during saving records as well.

On the current setup, coins inserted during score saving get recognized after the machine's done writing scores; I've inserted two coins during score saving, and after scores were written, I heard a louder-than-normal "coin insert" sound and the machine properly displayed 2/4 credits.

I've never seen it properly handle two coins during a load screen, but one of the Roxor patches attempted to address the problem (which moved it from always eating coins to usually remembering one coin, while also fixing a glitch would could double count a coin).  The louder than normal sound is the result of ITG catching up with the the input buffer; incrementing the credit counter and queuing a sound to be played takes only a few CPU cycles, so the two separate sounds are starting less than a microsecond apart, which is essentially simultaneous to a 44kHz sound card, so it winds up playing the sound twice as loud.

It's purely a software issue; during certain resource intensive operations (the most noticeable one - and possibly the only one - is the end-of-set save operation), the input thread is a low enough priority that it can be left sleeping until the input buffer has cleared.  OpenITG b3 raises the I/O thread priority in an attempt to mitigate or entirely fix the problem, but the OpenITG staff have not declared b3 stable for arcade use.  It should be arcade-ready, but they haven't gotten enough testing done to be sure.

The new computer will address this in multiple ways.

First, we're running a Core i3-2100 instead of the old Celeron.  An i3-2100 like the one we'll be using runs at 3.1 GHZ instead of ~2.5GHZ like a dedicab's stock Celeron  The i3 has the new Sandy Bridge architecture, which executes more instructions per clock cycle than the old Celeron's NetBurst architecture can.  It's also a dual-core hyperthreaded processor, so there's a good chance the input thread and the saving thread can execute in parallel.  If nothing else, an i3-2100 can hold its own in benchmarks against top of the line chips from a year ago (it can beat the AMD's six-core 3.3 GHZ Thuban in about 1 in 4 benchmarks), so if saving is slow because of any CPU related bottlenecks, they'll become a non-issue.

Secondly, the new computer has a better hard drive setup.  Both drives are SATA, instead of IDE.  This means much higher read/write bandwidth, further boosted by the fact that the two SATA drives run on parallel channels, whereas the current drives share their IDE channel.  There's little reason for the write speed to be affected by the shared channel, since the game pauses until it finishes saving, but still, it's worth noting that we should have much, much higher bandwidth.  Additionally, the drives are formatted with the ext4 filesystem, which performs slightly better than xfs, which the old computer uses.  I've also disabled some unnecessary metadata writes - by default, every time a file is opened, both xfs and ext4 will immediately update the file's metadata to indicate it was last opened right now - there's absolutely no reason to was time writing back the to drive every time we touch a file, so I'm disabling this option on most of the partitions (except the stats partition, which holds the saved data), which will free up the drives' write buffers and some of the bandwidth.

Thirdly, the rest of the hardware will help.  USB 2.0 means saving to drives is faster.  Two sticks of DDR3 RAM instead of 1 stick of DDR RAM means we have twice the bus width for accessing RAM, and the bus is clocked much, much faster, so getting the data from memory to the drive should only ever be bottlenecked by the drive bandwidth.

Fourth, I can't get OpenITG b2 to run from the pre-compiled package, so I've resorting to building OpenITG from source.  Both the b2 and b3 release tags are giving me trouble when I try to build them, but I'll get at least one of them up and running.  My goal is to get both working and set b2 as the default, so that I can do some b3 testing when I'm there and then switch it back to b2 before I leave.  Bill gave me a key on Saturday, so I can easily compensate players if b3 is unstable and ends up eating coins or crashing mid-set.

It's not just that the machine doesn't read quarters until after it's done saving scores; at that point, it just registers any you've inputted simultaneously after it's done saving, which I don't mind so much.

However, when transitioning from the title to the demo, the machine doesn't recognize the coins at all, which truly is an issue.  Will the input thread still be able to run in parallel while it's loading the demo?