..
..
Last edited by The Minder; 03-06-2011 at 08:25 PM.
I don't know that you're referring to me, but for the record, I never said it would be "too slow" to be useful. I was merely responding to the assertion that the host using SSD's would make a difference. It won't, because even the fastest internet connection has far less bandwidth that even an old, slow mechanical drive connection. Much less an SSD.Originally Posted by no luck involved
I would imagine for ordinary hand-by-hand importing and HUD usage, there probably won't be a dramatic difference in performance. OTOH running large batch imports, or reports/queries that return a large result set will take noticeably longer than with a local database.
True.
Also true. They take longer. But not in a way that really effects you. During the time critical operations (and that is while you are playing) you will not notice any difference between a local database and our service.
Importing a huge initial database is the biggest problem. When you have a slow connection, this process (which you only have to do once) will take a long time (depending on your upstream connection speed). Our backend provides you with the capability to upload a compressed archive file (7zip) which will save you around 60% of an uncompressed import, but if you have a huge database it still will take a long time.
I made the effort and tested this service with PT3 and HEM.
I have a 32mbit down/1mbit up connection with a ping of 12-16ms.
The date of testing was March 6-7, 2011
PT3
I created a PT database with the web-frontend. Had no trouble to connect to that database with the data provided by TB. I manually imported hands from big files for a couple of minutes. 25hands/s. all the housekeeping stuff worked flawlessly. Only issue was a couple of hand import errors that indicates that the prepared database uses UTF8 encoding while PT3 still uses ASCII. (On a second local test database I got no errors importing the same files.) I played 4 Rush tables with the almost empty database. No delays at all.
HEM
At the time of testing the task of preparing a database for HEM was broken (which is supposed to be fix by now). I created a test database and wanted to upload it by means of the provided script. That failed because I use Postgres 9 instead of Postgres 8 which comes with HEM. Support was kind enough to show me a workaround which worked and I was able to upload my database. Suprisingly for me it worked on a Postgres 8 server.
I initiated the same import as with PT3. Import speed was 10hands/sec.
This time I just played 2 Rush tables. No delay again.
I have a hotmail email address and apparently hotmail blocks the emails from trackerbase. Didn't even show up in the spam folder. I changed the email to a gmail one and everything was good.
Hope that helps anyone who considers using this service.
Cube... I understand what you're trying to do and I applaud you for your initiative, but introducing another level of complexity to a user base who need help just getting out of bed in the morning is not going to do it.
Let's talk timing. I have a DSL internet connection and the ping time from me to a major server only 40 miles away is 65ms. And that server is 12,000 miles from your server with a whole bunch of switches, routers, cables, fibre and assorted addons in the way. Yes, I understand about comms speeds approaching the speed of light etc, but that's not the issue. You're prolly best placed to do a speed test and I'm prolly worst placed. The average is somewhere in between, however the response time to my crappy old WD HD is 32ms so no matter what you or the rest of the internet infrastructure does you are not going to beat an in situ HD.
Let's talk backups. For more than 30 years in the IT game I have stressed to all my clients "don't bother with programs or operating systems, but back up your data". You're offering a backup service, but this is a backup of the db which is really inconsequential. The critical thing to backup is the hand histories, which you don't back up. Besides, every MS o/s since Win XP has had an auto backup/restore feature that works damn well. I'm also here to tell you that in all my time I have never once lost data off a client's HD... despite floods, lightning strikes and idiocy I have always recovered data. And this is something that any mom & pop computer store can do.
Let's talk mobility. You say we can access our data on your server from anywhere. Where am I going to go to want to use that feature?... and when I get there what computer am I going to use? I'm not going to use someone else's box just to play poker. I'm going to use my own laptop which has my db right there on the HD.
I could go on but I think you get where I'm coming from.
First of all, I want to say that lonelycube has nothing to do with this service. He did the test on his own. I'm not sure, but your post somehow sounds a little like you think that he is somehow involved with the project: That is not the case!
I just wanted to clarify that.
No one said, that the server beats your local Postgres server in speed. The thing is: It doesn't need to. Even a 500ms delay is by far fast enough. The data your HUD is using, is going to be cached anyways. The only disadvantage you get is that the Hold'em Manager startup process will take a little longer.
That is just wrong. Once you backup your database, you also backup your hand history. Because that is just a subset of all the data in the database. You have a backup of your database, you also have backup of all the hands you played plus the additional information.
This is actually exactly the use case this service was build for. I just hated the fact that whenever I played on with my laptop on the road, I had to sync back my database afterwards. Because normally of course I play on my big screen at my desktop. With this service there is no need to sync anymore. The automatic backup is just an extra to that fact. You can have a simple backup much easier (and probably cheaper).
@minder... I am laughing my head off. Im not a native english speaker but I love the phrase in your first paraphaph. maybe its just standard ;-)
Would be actually interesting if someone from the other side of the pond (that would be the US ;-) ) can give some info about speeds. especially on large databases.
I tried to exclude any assumptions in my report.
I only got into this because I made the sloppy statement about the SSD in the beginning and then got curious. the geek inside was calling.
I still think that the target group for this service is very small. including fast harddrives (SSDs maybe) might get the guys who import a lot and tablescan a lot and cant affort a SSD yet. Everyone who owns a SSD will likely agreed that it has been their best investment they ever made regarding speeding up their system. Providing an upload folder and import hands overnight on behalf of the user might be an idea as well. anyways..
Spent enough time here for just testing. Hope my input was appreciated.
good luck at the tables.
over and out
Yeah... my bad... I had too many threads open at the same time and confused my sel.
Apologies to Cube.
I do not agree with this. HM recently had an issue with incorrect EV calculation. The only was to resolve the issue (after updating to the corrected version) was to delete the hands from the db and reimport from HH. HH is always the first source data, the db is not.
Like cube, I shall now retire to the background. Gl with the project and at the tables.
Posting Permissions
Reply With Quote