IRC logs for #opendune on OFTC at 2009-10-13
⏴ go to previous day
08:05:53 *** TrueBrain has joined #openDune
08:16:53 <TrueBrain> something went terrible wrong with my connection
08:17:20 <Xaroth> ugh, might need to go figure out how to get an effective SAN+ESX sollution :/
08:17:56 <TrueBrain> Xaroth: in PR, if you don't want to say something, don't say anything at all
08:38:01 <Xaroth> hence why i linked it to you :P
08:38:23 <Xaroth> but it's a question that should be answered
08:38:37 <Xaroth> so it -should- be answered, but there's no nice way of telling it :P
08:38:55 <TrueBrain> nothing should be answered
08:41:17 <TrueBrain> brr .. today I am going to spend so much money .. going to buy a snowboard .. brr ..
08:42:44 <TrueBrain> hehe, yeah, concratz proyvind :)
08:42:51 <Xaroth> too bad your license is too limited :P
08:43:08 <TrueBrain> I also wonder if glx did wrote that unpak himself .. pretty fast, to make that :p
08:43:17 <Xaroth> from the old opendune project ;)
08:43:33 <Xaroth> or at least, the old opendune project had that same file on their svn
08:44:01 <TrueBrain> the fact that they had something similar, doens't make it the same ;)
08:44:06 <TrueBrain> but the files don't even look like eachother
08:44:44 <TrueBrain> so if that means glx found where PAK files are read ... impressive progress ;)
08:45:57 <Xaroth> hm, if he did he should come to holland so i can buy him a beer
08:53:03 <blathijs> There has been an opendune project before?
08:53:17 <TrueBrain> lucky enough they were dutch :)
08:54:04 <Xaroth> TrueBrain: you run esx+san clusters right?
08:54:34 <TrueBrain> yup, although last week I am ordered to review and deploy XenServer
08:54:44 <TrueBrain> which means we will move away from ESX(i) relative fast
08:54:56 <Xaroth> Xen? aren't they still relatively unstable?
08:55:14 <TrueBrain> they claim not to be, and my last tests show they are not. Just their admin-tool is crappy
08:55:24 <TrueBrain> oh, and don't run Xen on local IO, but use some kind of SAN :p
08:55:43 <TrueBrain> (performance LOSS was about 70%)
08:55:59 <Xaroth> heh, customer wants their own esx cluster (2x server), but they want twice our big monster machines
08:56:08 <Xaroth> which is.. kinda overkill for their purpose
08:56:15 <TrueBrain> power-wise stupid, but okay :)
08:56:51 <Xaroth> well the machines itself currently run 50+ instances together with not even 40% cpu/mem usage
08:57:00 <Xaroth> IO is a bit higher though, but that was expected
08:57:10 <TrueBrain> that is why you need to use iSCSI :)
08:57:15 <Xaroth> so I'm trying to find out if a san wouldn't be better for them
08:57:17 <TrueBrain> it offloads that completely
08:57:34 <TrueBrain> our performance win with iSCSI was in the order of 2 to 3
08:57:47 <Xaroth> just can't find good references to link to the pr dudes so they can make their story :/
08:58:00 <Xaroth> well, an old vmware doc about esx2.5 + san
08:58:56 <TrueBrain> google -> ESX iscsi benchmark :p
08:59:06 <TrueBrain> and there is no test like the live-test ;)
08:59:35 <Xaroth> benchmarks are biased :P
08:59:43 <Xaroth> live test is the best test :P
09:00:20 <TrueBrain> the simple story: when local IO, the process stalls till it receives word from the memory/disk, but mostly disk, as there is so much IO. Also, the CPU needs time to handle this IO. iSCSI offloads it all to another CPU, which does keep his IO cache (because it has memory to waste on it). Now when an IO command is stalling, the ESX can just continue with other VPSes, and never has to waste any time on the IO, till the iSCSI reports ready
09:00:30 <TrueBrain> you will read that on any site benchmarking these 2
09:00:42 <TrueBrain> the biggest problem is that you can't build an IO cache
09:01:37 <TrueBrain> (on the ESX machine)
09:01:42 <TrueBrain> either way, got to go
09:37:40 *** Xaroth sets mode: +o TrueBrain
12:51:28 <Xaroth> glx: did you build that unpak thing?
12:52:02 <Xaroth> 10:46 <@Xaroth> hm, if he did he should come to holland so i can buy him a beer
12:52:06 <Xaroth> come to holland, get beer :P
12:57:52 <glx> french translation is not very good, and english is the only language with different voices for each house
12:59:02 <glx> but the funny part is the intro, some sentences are a a succession of different .voc
12:59:29 <Xaroth> same way how satnavs work :P
19:44:12 <TrueBrain> glx: I am impressed you could figure that out ;) Nice job :)
19:44:35 <TrueBrain> about your patch: first 1 fields miss length (1)
19:45:19 <glx> for unpak I just opened a .pak in hexviewer :)
19:45:21 <TrueBrain> the 'char' fields don't align nicely ;)
19:45:33 <glx> then it's easy to understand how to unpak
19:46:19 <glx> for the strings I just use msvc ;)
19:46:54 <TrueBrain> oh, only the first 3 chars dont align ;)
19:50:05 <glx> struct_7B68 doesn't align very well either ;)
19:51:03 <glx> I could use [6][6] without a struct, but a struct is better I think
19:51:06 <TrueBrain> nothing you can do about that ;)
19:51:12 <TrueBrain> yes, struct, please, struct :)
19:52:17 <glx> string comments are correctly formatted for doxygen ?
20:03:34 <TrueBrain> the rest is commitable for me glx :)
20:03:49 <TrueBrain> (I forgot to mention that 10 minutes ago I noticed .. pressing enter can be useful)
20:05:32 <DorpsGek> SVN: glx (r281) -Add: figured out a few variables (+ some style fixes)
20:06:29 <glx> scenario.pak contains nice stuff :)
20:06:52 <glx> like where is enemy at start
20:07:45 <glx> and maps are generated using a seed
20:11:58 <TrueBrain> now figure out where and when it is loaded ;)
20:12:01 <glx> they use a human readable format, and that's good :)
20:12:36 <TrueBrain> scritps attached to units and stuff are compiled, but nicely readable after decompiling :)
20:12:37 <glx> I already tried to follow dune.cfg loading ;)
20:13:42 <glx> I think it starts dune.cfg loading in f__B480_0000_0018_A09B()
20:54:11 <TrueBrain> tomorrow another day of Dune hacking :)
20:56:02 <glx> not much progress today ;)
21:01:08 <SmatZ> good night good TrueBrain :)
continue to next day ⏵