| 04:31.01 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 04:43.00 | *** join/#bzflag JeffM (~JeffM@2605:e000:7d02:c700:a978:4adc:c143:57a0) |
| 05:10.43 | *** join/#bzflag alpha1-2 (~alpha1-2@host31.190-224-22.telecom.net.ar) |
| 05:14.32 | alpha1-2 | Hi, why the download when you try to join a server and it has "world" features to download, is terribly slow? |
| 05:14.54 | JeffM | you mean textures? |
| 05:15.20 | alpha1-2 | it says: |
| 05:15.59 | alpha1-2 | "Downloading World (NN% complete/NNN kb remaining)..." I am not sure which kind of features |
| 05:16.18 | JeffM | thats the map then |
| 05:16.45 | JeffM | there are 2 ways the server can provide the map |
| 05:16.50 | JeffM | one is fast, one is slow :) |
| 05:17.11 | alpha1-2 | I always have noticed that that speed is terribly slow comparated with/to the normal downloading speed |
| 05:17.24 | JeffM | the older, slower way, is limited to 1000 bytes per lag time |
| 05:18.20 | alpha1-2 | "per lag time" what is this? |
| 05:18.38 | JeffM | actualy it's 2x lag time |
| 05:18.43 | JeffM | the time between you and the server |
| 05:18.52 | JeffM | the server sends you 1000 bytes |
| 05:18.58 | JeffM | you say "give me another" |
| 05:19.04 | JeffM | then the server sends you another 1000 bytes |
| 05:19.29 | alpha1-2 | wait, but each how much time, if I have 350 ms for example |
| 05:19.33 | JeffM | so 1000 bytes takes as long as it takes for a message to go back and forth between you and the server |
| 05:19.47 | JeffM | then 700ms |
| 05:19.51 | JeffM | for 1000 bytes |
| 05:19.57 | alpha1-2 | okay, stop there |
| 05:20.00 | JeffM | regardless of how much actual bandwith you have |
| 05:20.02 | alpha1-2 | see this example |
| 05:20.17 | alpha1-2 | fist time it happens to me |
| 05:20.51 | alpha1-2 | a new map called "Pirates of the Raging Seas" |
| 05:21.00 | JeffM | it has nothing to do wiht them map file |
| 05:21.03 | JeffM | it's the server |
| 05:21.10 | alpha1-2 | started saying |
| 05:21.20 | alpha1-2 | "1200 kb to download" |
| 05:21.24 | alpha1-2 | yes? |
| 05:21.29 | JeffM | probalby because the map is large |
| 05:21.41 | alpha1-2 | the biggest in 2 years to me |
| 05:21.55 | JeffM | if the server runs the fastmap plugin it will download over HTTP and can be faster |
| 05:21.57 | alpha1-2 | and the downloading tim is terrible |
| 05:22.10 | JeffM | it should only happen once |
| 05:22.11 | alpha1-2 | too terrible that it *stopped downloading*! |
| 05:22.13 | JeffM | and be cached |
| 05:22.28 | alpha1-2 | it downloaded until 80% and stopped! :( |
| 05:23.00 | alpha1-2 | but I went to Youtube and my monitor measured instead of 4 Kib/s, 400! |
| 05:23.08 | alpha1-2 | why? |
| 05:23.33 | *** join/#bzflag JeffM (~JeffM@2605:e000:7d02:c700:a978:4adc:c143:57a0) |
| 05:24.04 | alpha1-2 | why? |
| 05:24.21 | alpha1-2 | I have pics also, it said: " |
| 05:24.48 | JeffM | the older method doesn't work well with large maps |
| 05:25.03 | JeffM | there was talk of making fastmap default |
| 05:25.08 | alpha1-2 | "88% complete..." and a red message appeared in the console: |
| 05:25.32 | alpha1-2 | "failed to connect within reasonable timeframe" |
| 05:25.40 | alpha1-2 | and then I have to start again |
| 05:25.41 | JeffM | yeah you timed out |
| 05:25.50 | alpha1-2 | from 0% |
| 05:25.50 | JeffM | my guess is you don't have a great connection to that server |
| 05:26.26 | alpha1-2 | no, I always have had this kind of slow download |
| 05:26.38 | alpha1-2 | in every map I think, if I am not wrong |
| 05:27.06 | alpha1-2 | much slower than any other download I do, it must be the older method, as you say |
| 05:27.33 | DTRemenak | servers with large maps should really be using -cache |
| 05:28.35 | alpha1-2 | looking at that option |
| 05:28.36 | JeffM | yeah that's what fastmap automaticly does |
| 05:28.55 | JeffM | alpha1-2, you can't change what method the server uses |
| 05:28.56 | DTRemenak | you probably just won't be able to play on that server, unless you convince the server owner to use -cache or fastmap, or get a mapcache from someone else |
| 05:31.11 | alpha1-2 | oh I see, then the binary file is much smaller than the original, right? |
| 05:31.28 | alpha1-2 | or it uses HTTP instead and much faster? |
| 05:31.34 | DTRemenak | it's a bit smaller, but it's also sent via a method that doesn't suck ;) |
| 05:32.11 | alpha1-2 | which is the other method/protocol? |
| 05:33.00 | DTRemenak | -cache specifies a url with the mapcache. the url is normally served with a web server via http, and is therefore quite fast (but it can be done via ftp, or any other protocol supported by libcurl) |
| 05:33.59 | DTRemenak | fastmap hosts locally via http. -cache is more efficient, but less flexible. |
| 05:34.10 | JeffM | yeah, fastmap does that automaticly and sets up an internal HTTP server that isn't tied to the game protocoll |
| 05:34.20 | JeffM | exactly |
| 05:34.26 | JeffM | it still uses bandwith and CPU of the server |
| 05:34.36 | JeffM | but it's better then the legacy method |
| 05:34.41 | JeffM | best is to use a fast webcache |
| 05:34.53 | alpha1-2 | which method/protocol is the older one? |
| 05:35.12 | alpha1-2 | is/use* |
| 05:35.16 | JeffM | the 1000 bytes per lag |
| 05:35.26 | DTRemenak | if you use neither fastmap nor -cache, it's sent over the bzfs protocol, one kb pre round trip. |
| 05:35.31 | JeffM | yeah |
| 05:35.39 | JeffM | that method is always available |
| 05:35.47 | JeffM | so it's the default |
| 05:36.58 | alpha1-2 | anyways, if I have 350 ms with that server and it takes 4 KiB/s, that doesn't make sense. You said 700 ms for 1000 KB, and the map has 1200. I was waiting about... 2 minutes total! |
| 05:37.18 | DTRemenak | 1000 bytes, not kb |
| 05:37.28 | alpha1-2 | oh |
| 05:37.48 | DTRemenak | just off by three orders of magnitude ;) |
| 05:37.52 | alpha1-2 | hehe |
| 05:38.23 | alpha1-2 | that is terrible yes! haha |
| 05:38.58 | alpha1-2 | 1 KB... |
| 05:39.01 | alpha1-2 | hehe |
| 05:39.07 | JeffM | slightly less then 1kb ;) |
| 05:39.07 | alpha1-2 | I see now |
| 05:39.21 | alpha1-2 | true :) |
| 05:39.25 | alpha1-2 | 1024! |
| 05:40.16 | alpha1-2 | well, I know the admin, I will try to convince him |
| 05:40.38 | DTRemenak | if he is running a webserver anyway, -cache is super simple to set up |
| 05:40.42 | JeffM | yeah |
| 05:40.59 | alpha1-2 | wow, then this method has its time, true? how long is it? fom the start? |
| 05:41.07 | alpha1-2 | from* |
| 05:41.30 | JeffM | it sends the entire map bin |
| 05:42.11 | alpha1-2 | no, I mean the 1000 k/lag, is the fist method implemented in the game 20 years ago or how long? |
| 05:42.18 | alpha1-2 | 1000 b* |
| 05:42.22 | DTRemenak | yes, that's the original method |
| 05:42.23 | alpha1-2 | first* |
| 05:42.28 | JeffM | yeah since the start |
| 05:42.34 | DTRemenak | boxes and pyramids are small ;) |
| 05:42.34 | alpha1-2 | ah I see, wow :) |
| 05:42.49 | alpha1-2 | oh then textures are he biggest |
| 05:42.51 | DTRemenak | it was rare that the entire map wouldn't fit in one chunk |
| 05:42.55 | alpha1-2 | the* |
| 05:43.03 | DTRemenak | textures are downloaded separately...the map mechanism is used for geometry only |
| 05:43.12 | alpha1-2 | ohhh |
| 05:43.18 | DTRemenak | meshes are big |
| 05:43.23 | alpha1-2 | then the map is relly big I suppose |
| 05:43.27 | alpha1-2 | really* |
| 05:43.43 | alpha1-2 | ah meshes, sorry |
| 05:44.02 | alpha1-2 | but, really, the first time in 2 years |
| 05:44.11 | alpha1-2 | the biggest map for me |
| 05:44.27 | JeffM | the origonal did not support textures |
| 05:44.33 | alpha1-2 | and the connection to that map is not the bst 350ms |
| 05:44.43 | JeffM | yeah that's going to be slow for you |
| 05:44.54 | alpha1-2 | server* |
| 05:45.43 | alpha1-2 | we are having problems with lag limit there, we are studying the case, first server in USA hat I have too high lag |
| 05:46.32 | JeffM | what is it hosted on? a cheap VPS? |
| 05:46.42 | alpha1-2 | we are not sure still, we will wait 2 weeks to see if the problem is not mine. I have usually 200 in USA, 300 in Europe. |
| 05:47.38 | alpha1-2 | it seems the problem is only for me, though I think I see other players with higher lags than the usual |
| 05:47.53 | DTRemenak | you have about 120ms speed-of-light lag, by my estimate. 350 for you should mean people in the US will be around 200ms lag, which is pretty terrible. |
| 05:47.57 | alpha1-2 | it is a VPS in California |
| 05:48.21 | alpha1-2 | not sure if it is cheap or not |
| 05:48.40 | alpha1-2 | but in allej-o's ones I am fine |
| 05:48.50 | alpha1-2 | (VPS too) |
| 05:49.49 | DTRemenak | ah, california is worse for you...the main trunk lines from south america run up through the carribean to florida iirc |
| 05:49.59 | JeffM | lower end VPSs can get fake lag beause they don't have the CPU cycles |
| 05:50.34 | JeffM | or the cycles are not consistent |
| 05:50.39 | JeffM | or yea, routing |
| 05:50.59 | alpha1-2 | but in ARPA:NET (California) I have... 270ms |
| 05:51.16 | JeffM | not eveyrone routes the same |
| 05:51.37 | DTRemenak | 80ms could easily be server-related, like JeffM was saying |
| 05:51.52 | alpha1-2 | but lately, I usualy have around 200, then we will wait, maybe some area or general problems, or it was me |
| 05:52.11 | JeffM | there is the 512k problem |
| 05:52.44 | DTRemenak | allejo's servers are in Ohio, so you're ~50ms closer to them |
| 05:53.02 | alpha1-2 | it says NYC |
| 05:53.17 | DTRemenak | about the same |
| 05:53.33 | alpha1-2 | reading |
| 05:53.38 | DTRemenak | I have columbus, OH written down for them...but it's some years old |
| 05:53.43 | alpha1-2 | reading chat |
| 05:55.21 | alpha1-2 | I don't und. the half of what you said (some weird), but no need to explain me it now :) |
| 05:55.36 | alpha1-2 | I just hope you are not joking at me |
| 05:55.49 | JeffM | there are many reasons you could have lag |
| 05:55.54 | alpha1-2 | (in the last part) |
| 05:55.57 | JeffM | with out other info there is no way to know |
| 05:56.02 | JeffM | that's the basics :) |
| 05:56.41 | DTRemenak | does the 2.4 server do collision checking? |
| 05:57.14 | JeffM | nope |
| 05:57.19 | alpha1-2 | <DTRemenak> "... 350 for you should mean people in the US will be around 200ms lag, which is pretty terrible." |
| 05:57.40 | alpha1-2 | I have the value of a US's player... |
| 05:57.51 | Snake12534 | alpha1-2, where are you located? |
| 06:00.48 | alpha1-2 | I found it |
| 06:01.12 | DTRemenak | alpha1-2: that means, some of your lag is due to physical distance. speed of light communication from you to florida is ~120ms delay. So a US player in Miami *should* have ~120ms less lag than you, if there was no routing delay (probably more like 150ms with routing). |
| 06:01.51 | alpha1-2 | this friday, 20 UTC-3, I had 359ms and D3ad Turtle, I und. he is form USA, had 148 |
| 06:02.13 | JeffM | The US is not a super small country |
| 06:02.52 | alpha1-2 | but not 200ms DTRemenak |
| 06:02.55 | allejo | fwiw, archive.bzflag.allejo.io is Columbus, Ohio. bzflag.allejo.io is New York, New York |
| 06:04.40 | DTRemenak | alpha1-2: california to florida is ~40ms more. if he was a Californian player, that's pretty close to expectations. But that would be terrible lag for him...a local server should be more like 30ms ;) |
| 06:05.34 | DTRemenak | so there's a lot of "unaccounted" lag...which could be due to server conditions, etc |
| 06:05.38 | alpha1-2 | I see other players having: 42, 45 and 50. Then, 111, 131, 148, etc |
| 06:05.59 | DTRemenak | or just bad peering agreements |
| 06:06.17 | DTRemenak | verizon and so on ;) |
| 06:06.25 | JeffM | alpha1-2, you don't have enough info to know what those times mean |
| 06:07.21 | alpha1-2 | then 148 for a USA's player is acceptable or it is bad and then the server had problems? |
| 06:07.23 | DTRemenak | for instance, check http://internetpulse.net/ - that's a table of current peering-related latency |
| 06:07.55 | DTRemenak | at&t and verizon are not getting along at the moment, so a player on one connecting to a server on the other could get as much as 80ms lag just from peering |
| 06:09.39 | alpha1-2 | 80 + 40 = 120. To 148 it has 28 more. Then you tell that it is okay? |
| 06:10.21 | DTRemenak | 30ms or so is local, in good conditions |
| 06:10.42 | alpha1-2 | ah okay, then + 30 is okay. Done :) |
| 06:10.46 | DTRemenak | in bad conditions it can be much worse. but that is something that the host has control over, unlike routing, peering, and the speed of light |
| 06:11.09 | alpha1-2 | oh optic fibre you mean? |
| 06:11.20 | JeffM | laws of physics |
| 06:11.23 | alpha1-2 | I thought you were some joking at me :P |
| 06:11.31 | JeffM | no signal on any medium can travel faster then liight |
| 06:11.44 | JeffM | and light takes several MS to travel over this planet |
| 06:11.55 | DTRemenak | your total lag is basically: endpoint lag (server), routing (remote), peering, speed-of-light, routing (local), and endpoing lag (local) |
| 06:12.07 | alpha1-2 | optic fiber is ligth speed, JeffM, if I am no wrong |
| 06:12.16 | JeffM | it is close to it, yes |
| 06:12.38 | JeffM | well it's one of the speeds of light |
| 06:12.40 | DTRemenak | the speed of light in optic fiber is slower than the speed of light in a vaccuum (by about 40%) |
| 06:12.42 | JeffM | the speed of light in glass |
| 06:12.46 | JeffM | yah |
| 06:12.59 | JeffM | light travels different speeds in diferent things |
| 06:13.04 | alpha1-2 | oh 40% is much! |
| 06:13.12 | alpha1-2 | much low* |
| 06:13.14 | DTRemenak | at "local" ranges, endpoint lag and routing dominate your total lag |
| 06:13.37 | DTRemenak | when your endpoints are on different continents, it is a BIG factor |
| 06:15.06 | alpha1-2 | and the last question, DTRemenak, that table in the web page means when and how the providers work? |
| 06:15.29 | DTRemenak | yeah, that's the transition time to get a packet off one network and onto one of its peers |
| 06:16.06 | DTRemenak | usually those numbers are small. numbers like "1" and "8" are good, they mean there's pretty much no peering lag. numbers like "76" that we have now are quite bad. |
| 06:16.45 | DTRemenak | it means you have 76 ms of lag to get from one router owned by one company to a router owned by a different company in the same building |
| 06:17.31 | alpha1-2 | oh, and the black box (selected)? |
| 06:17.59 | DTRemenak | just follows your "focus" selection at the top, I think |
| 06:18.29 | alpha1-2 | ah okay, very interesting |
| 06:18.56 | alpha1-2 | well, thanks, guys. Not more for now. :) |
| 06:18.59 | DTRemenak | it's not symmetric...often getting from network A to network B is very much harder/slower than getting from network B to network A. |
| 06:19.16 | alpha1-2 | ah |
| 06:20.00 | *** join/#bzflag thrakattak (cz3141@gateway/shell/devio.us/x-drdvngyqqpswfkzb) |
| 06:21.25 | DTRemenak | just as a test, from me (at&t in california) to telecom.net.ar's border router is about 235ms at the moment |
| 06:23.58 | alpha1-2 | my chat client says 206 ms rightnow |
| 06:24.07 | alpha1-2 | oh 302 now :P |
| 06:24.22 | JeffM | IRC is not a good measure of ping ;) |
| 06:24.44 | alpha1-2 | hmm then I am having some issuea lately, yes (or the area or the Interent in general) |
| 06:24.51 | DTRemenak | looks like 23 ms to the at&t backbone from here. 180ms more transitioning to seabone in b. aires. the rest within telecom.net.ar's network. |
| 06:25.10 | alpha1-2 | 205ms again |
| 06:26.36 | alpha1-2 | are you using some console tools, DTRemenak? |
| 06:26.38 | DTRemenak | and I was right, seabone does jump in maimi |
| 06:26.51 | DTRemenak | just tracert for that |
| 06:27.02 | DTRemenak | and ping |
| 06:27.05 | alpha1-2 | okay |
| 06:27.22 | alpha1-2 | I will try too |
| 06:29.45 | alpha1-2 | to miami 213 |
| 06:30.36 | alpha1-2 | well, I get 250 ping to phatomzone.org, like early yesterday |
| 06:31.06 | alpha1-2 | but there were no player on it at that time |
| 06:31.16 | DTRemenak | that's your "base" lag to the US. the best condition possible to a US server will give you ~240ms lag (213 + 30-ish). |
| 06:32.15 | JeffM | he needs a tachyon burst |
| 06:32.15 | alpha1-2 | I will try to download it again now |
| 06:32.29 | alpha1-2 | 5 players on now BTW |
| 06:32.47 | DTRemenak | phantomzone is in NY, so you're getting a very small additional amount from miami to there, which is what I'd expect...the east coast trunk line is about as good as they come ;) |
| 06:33.34 | alpha1-2 | oh and I forgot, when I try to rejoin, after the failed download, it says "Error on md5. Removing offending file." I guess the corrupted file. |
| 06:33.53 | JeffM | you probably have packetloss |
| 06:33.54 | DTRemenak | yeah, if the map download gets interrupted, the cache gets left in a bad state |
| 06:34.05 | Flash | I'm getting a very slow download from phantomzone too |
| 06:34.05 | JeffM | and that |
| 06:34.07 | alpha1-2 | never do a "continue" method ;) |
| 06:34.28 | alpha1-2 | (like wget) |
| 06:34.34 | JeffM | I belive fastmap supports ranges properly |
| 06:34.39 | DTRemenak | if your server uses -cache, you'll get resume support |
| 06:34.45 | alpha1-2 | oh nice! |
| 06:34.54 | DTRemenak | hm, that's fancy...I wouldn't have expected it from fastmap :) |
| 06:34.59 | alpha1-2 | I see, I see, all is about the older method |
| 06:35.18 | alpha1-2 | let's see if I pass the 88% this time! |
| 06:35.20 | JeffM | IIRC I did it when I redid the HTTP system te second time |
| 06:35.24 | DTRemenak | neat |
| 06:35.41 | JeffM | or I may be thinking of the third time I did it that's not in bzflag |
| 06:35.45 | DTRemenak | heh |
| 06:36.52 | JeffM | I recall being much happier with the current 2.4 implementation |
| 06:37.02 | alpha1-2 | what? into the Unity version maybe? :) |
| 06:37.21 | JeffM | oh god no |
| 06:37.25 | alpha1-2 | hehe |
| 06:37.25 | JeffM | it has it's own tools for that |
| 06:37.35 | JeffM | I've used the HTTPD I did for other stuff |
| 06:38.03 | alpha1-2 | when he uses "god" I am not sure if he is getting... upset, scary or any other thing :) |
| 06:38.42 | alpha1-2 | comeone 94%! |
| 06:38.45 | alpha1-2 | come on* |
| 06:38.48 | JeffM | be worried when I use gods |
| 06:38.59 | alpha1-2 | oh no 96%!!! |
| 06:39.03 | alpha1-2 | :(( |
| 06:39.06 | alpha1-2 | haha |
| 06:39.18 | alpha1-2 | 41 kb remaining! |
| 06:39.43 | alpha1-2 | well, I know what to do now, guys, thanks again :) |
| 06:42.00 | alpha1-2 | and Snake12534, you know I am from Argentina |
| 06:45.20 | Snake12534 | ah |
| 06:46.30 | alpha1-2 | Flash: could you join that server finally? |
| 06:49.10 | alpha1-2 | oh, he is already happily playing on there :) http://bzstats.strayer.de/players/stats/?name=flash&lang=en |
| 06:49.27 | alpha1-2 | glad for him :'( |
| 06:49.56 | alpha1-2 | send me a postal at least, Flash! :D |
| 06:50.02 | alpha1-2 | postcard* |
| 06:54.02 | alpha1-2 | excuse me, am I annoying if I continue a lil? |
| 06:54.18 | alpha1-2 | little* |
| 06:59.15 | alpha1-2 | because I *can* play Wall of China now for the first time (in the same server). Then, as Jeff said about cheap VPSs, is it possible that when there are several players on it, they make lag increasing ("fake lag") cause of "CPU cycles" not continous or unavailable? (I have now 250 and then 350 or 400). Maybe also the Internet availabilty at higher demanding time. |
| 07:00.09 | DTRemenak | yes, a busier server will lag more than an emptier one...the longer the server takes to complete an update cycle, the more lag you'll get |
| 07:00.21 | alpha1-2 | All seems rather weird for me and for the server admin. |
| 07:01.12 | alpha1-2 | but it seems an huge difference to me if it is only cause of the server lag (real lag, not fake one) |
| 07:01.19 | alpha1-2 | about 100/150 more! |
| 07:01.43 | alpha1-2 | now: 1 player; then:10 players |
| 07:02.29 | alpha1-2 | then, maybe it must be the VPS quality mostly, I guess |
| 07:02.59 | DTRemenak | lots of things can make update cycles take longer. number of players/shots is the most significant. |
| 07:03.32 | DTRemenak | but a poorly-behaved plugin could do the same |
| 07:05.17 | alpha1-2 | oh, let me see if he has plugins on there |
| 07:05.31 | Snake12534 | http://unity3d.com/learn/tutorials/modules/beginner/scripting/on-mouse-down |
| 07:05.40 | alpha1-2 | no plugins |
| 07:06.51 | DTRemenak | the amount of work that a server has to do is proportional to the number of players squared, plus the number of players times the number of shots. there are other factors, most of which fade to the background pretty quickly as player count increases. |
| 07:08.21 | alpha1-2 | but, in your opinion, you think then it is cause of a bad quality VPSs mostly in this case? |
| 07:08.26 | alpha1-2 | also* |
| 07:09.50 | DTRemenak | could be. have the admin run top when the load is high, and see if bzfs is consuming a lot of cpu |
| 07:10.26 | DTRemenak | and check the load average...anything over 1 is going to cause problems for bzfs |
| 07:10.36 | DTRemenak | it's not especially tolerant |
| 07:11.31 | alpha1-2 | ohh I see better now |
| 07:12.12 | alpha1-2 | then 1 is the top or it can be higher? |
| 07:13.00 | DTRemenak | "top" is a command that will indicate cpu utilization for a particular process. if bzfs is using more than around 50% cpu, it means it's probably adding significantly to lag. |
| 07:13.12 | DTRemenak | load average is a calculation of the overall load on a system |
| 07:13.20 | DTRemenak | 1.0 means full utilization of one thread |
| 07:13.34 | DTRemenak | 0.5 means 50% idle time on a single core machine |
| 07:14.20 | DTRemenak | so if bzfs' own instantaneous utilization is over 50%, or the system average as a whole is over 100%, you'll have some problems. |
| 07:14.34 | alpha1-2 | I know the "top" command, just it seamed weird to me a value higher than 1 :) |
| 07:14.47 | DTRemenak | load averages for production servers are often >1 |
| 07:15.15 | DTRemenak | especially on multi-cpu machines |
| 07:15.41 | DTRemenak | on a vps, though, you don't have that freedom (and you may not even have an entire core to yourself) |
| 07:16.34 | alpha1-2 | I have a 2 cores CPU and I have 0.80, 0.58. 0.48. Not pretty sure why 3 values and thoe values |
| 07:17.20 | alpha1-2 | 0.80, 0.58, 0.48* |
| 07:17.36 | alpha1-2 | (load average) |
| 07:17.50 | DTRemenak | inexpensive vps' often over-subscribe, so they'll have sold more CPU time than is actually available, betting that not everyone will be using it at the same time (or using a floating average) |
| 07:18.04 | DTRemenak | that can be pretty bad for latency-dependent processes like bzfs |
| 07:18.08 | alpha1-2 | but really > 1 in production servers? that would be overloading I guess |
| 07:18.44 | DTRemenak | alpha1-2: it's not normalized. 4.0 on a four-core machine is 100% utilization. |
| 07:19.08 | DTRemenak | and some overloading is not uncommon |
| 07:19.30 | DTRemenak | it means that low-priority processes are getting less cycles than they request, which is usually ok |
| 07:20.04 | DTRemenak | of course when you see 8.0 on a single-cpu box you should still be worried ;) |
| 07:20.10 | *** part/#bzflag Snake12534 (635cd32e@gateway/web/freenode/ip.99.92.211.46) |
| 07:20.35 | DTRemenak | the three values are minute, 5 minute, 15 minute |
| 07:20.36 | alpha1-2 | (hehe Snake "leaving", he is learning) |
| 07:21.17 | alpha1-2 | oh okay, I was going to check that |
| 07:21.23 | DTRemenak | so in your example, your computer's load is higher in the last minute than it was averaged over the last 15 |
| 07:22.10 | alpha1-2 | yes, as I posted long time ago, BZ consumes a lot in my machine, though I think it is mostly for the 3D system |
| 07:22.27 | alpha1-2 | (onboard) |
| 07:22.42 | alpha1-2 | checking |
| 07:22.52 | DTRemenak | yes, intel gpus are very, very cpu-hungry |
| 07:23.29 | alpha1-2 | http://forums.bzflag.org/viewtopic.php?f=42&t=18633 |
| 07:24.51 | alpha1-2 | I just posted it cause it seemed very interestin to me and to share, cause my machine is some low featured, then we can measure how much BZ consumes |
| 07:26.23 | alpha1-2 | but I felt, after the first answer, like it didn't seem very interesting for you finally... |
| 07:26.26 | DTRemenak | if you're really curious about whether it's bz or your graphics drivers sucking up your cpu, run a profiler on it (oprofile is a great choice if you have kernel support for it). that'll tell you where the cpu time is being spent |
| 07:26.57 | DTRemenak | but it's not an especially interesting problem in general, since we already know intel graphics eat cpu |
| 07:29.11 | alpha1-2 | but what is the problem, if the CPU is Intel and the GPU is onboard, it is supposed to consume CPU, or not? Unless it has an NVidia onbard card with much memory and processor. Do you know other brand apart from Intel that doesn't consume its own CPU? |
| 07:29.52 | DTRemenak | these days, AMD's A-series is about as CPU-efficient as they come. |
| 07:29.54 | alpha1-2 | AMD for example? |
| 07:30.23 | DTRemenak | radeons and geforces both take some CPU for "prep work" (texture format conversion, for example) |
| 07:30.40 | Flash | alpha1-2: yeah, I was playing |
| 07:30.43 | DTRemenak | and intel actually runs a lot of GL code on the CPU itself, instead of handing it off to the GPU |
| 07:31.22 | alpha1-2 | I'm glad Flash! Coul you please send me a picture of that map? I am not sure I will b able to play there soon case of my problems |
| 07:31.36 | alpha1-2 | (oh my keyboard!) |
| 07:31.57 | alpha1-2 | (it seems interesting) |
| 07:32.35 | alpha1-2 | (and sometimes the maps dissapears in few time) |
| 07:33.08 | alpha1-2 | or maybe my GPU has not much memory/processor? |
| 07:33.24 | DTRemenak | it has no memory at all...IGP shares the memory with the CPU |
| 07:33.48 | DTRemenak | that's one reason Intel likes to shift processing work to the CPU...it costs them nothing in terms of memory bandwidth to do it |
| 07:34.03 | alpha1-2 | I thought too that maybe what I saw in those monitors (post) were directly my GPU working "Into" my CPU, let's say, and I wondered |
| 07:35.27 | alpha1-2 | I thought that maybe I was just seeing my GPU being measured into them, I mean |
| 07:35.46 | alpha1-2 | wow, we can share files on there? nice! |
| 07:36.09 | Flash | that remains to be seen |
| 07:36.13 | Flash | still trying |
| 07:36.26 | alpha1-2 | yes I do now |
| 07:36.26 | DTRemenak | just remember that both Intel and AMD prefer to play to their strengths. Intel has excellent CPUs and poor GPUs, so they move a lot of processing work from the GPU to the CPU. for AMD the situation is reversed...their GPU hardware is top-notch, and their CPUs are mediocre. |
| 07:37.03 | alpha1-2 | this is suppposed to be safe right? :S (first time) |
| 07:37.29 | DTRemenak | only do it with people you trust, and use protection ;) |
| 07:37.52 | alpha1-2 | wait haha |
| 07:38.19 | alpha1-2 | which kind of risks could I have? |
| 07:38.33 | Flash | there are attacks from malicious gifs |
| 07:38.38 | DTRemenak | same as any other file transfer, pretty much |
| 07:38.44 | Flash | but this is a PNG so should be relatively safe |
| 07:38.56 | DTRemenak | my statement was a bad joke ;) |
| 07:39.04 | alpha1-2 | oh just the file ok, it said "failed" |
| 07:43.58 | alpha1-2 | wonder why it failed though |
| 07:45.37 | alpha1-2 | that is why I refered to, DTRemenak. You blame Intel onbaord GPUs. And I asked if you know another onboard one (not Nvidia, Radeon, etc.) that is better (AMD, other) |
| 07:46.02 | alpha1-2 | what I refered to* |
| 07:46.34 | alpha1-2 | I trust Intel uses good technology |
| 07:47.53 | alpha1-2 | oh, nice map, Flash, thanks again! |
| 08:09.12 | khonkhortisan | pong |
| 08:29.30 | *** join/#bzflag khonkhortisan2 (~kyle@2601:8:8600:97f:4a5b:39ff:fe94:be23) |
| 13:40.12 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 15:45.24 | *** join/#bzflag JeffM (~JeffM@2605:e000:7d02:c700:75cd:b61d:fa99:aa84) |
| 16:36.34 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 18:27.30 | *** join/#bzflag khonkhortisan2 (~kyle@2601:8:8600:97f:4a5b:39ff:fe94:be23) |
| 18:42.51 | *** join/#bzflag snake12534 (635cd32e@gateway/web/freenode/ip.99.92.211.46) |
| 18:43.30 | *** join/#bzflag khonkhortisan (~Khonkhort@c-71-227-239-229.hsd1.wa.comcast.net) |
| 19:20.28 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 19:34.25 | *** join/#bzflag alpha1-3 (~alpha1-2@host31.190-224-22.telecom.net.ar) |
| 19:37.30 | alpha1-3 | about Ducati: Hi, whom should I send a bug about the website to? Apart, the site says "Send Chestal a mail", where is his mail? or it means PM? |
| 19:38.44 | kierra | send it to osta |
| 19:38.47 | kierra | :D |
| 19:39.10 | alpha1-3 | oh, okay. Thanks, Ducati's secretary ;) |
| 19:39.36 | alpha1-3 | *secretary** |
| 19:40.37 | alpha1-3 | ehmm, and about the programming specifically? also to him? |
| 19:43.39 | blast007 | yeah |
| 19:43.55 | alpha1-3 | okay |
| 19:44.37 | alpha1-3 | just cursiosity now, isn't ts the same maintainer for it? |
| 19:44.45 | blast007 | no |
| 19:44.55 | blast007 | different fork of the project |
| 19:45.19 | alpha1-3 | ah, and who was the forker? Chestal? |
| 19:46.25 | blast007 | I don't think so.. think the ducati one is based on the one ts made |
| 19:48.12 | alpha1-3 | yes, that is why I mentioned ts at the start. Then, you are not sure who is the maintainer, if it is one. Okay. |
| 19:48.27 | alpha1-3 | if there is one* |
| 19:48.30 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 19:49.04 | alpha1-3 | both sites are pretty similar, though Ducati has some nice suplementary things |
| 19:49.21 | alpha1-3 | chat, graphs, etc |
| 19:49.29 | brad | osta added that stuff |
| 19:49.35 | alpha1-3 | ahh okay |
| 19:49.40 | brad | he's on bz now if you want him |
| 19:50.07 | Chestal | I never worked on any incarnation of the web code for the league |
| 19:50.31 | alpha1-3 | well, just to comment, and I will ask him, I wonder why the GULeague shows players but Ducati doesn't |
| 19:50.37 | allejo | bzion will beat bz-owl *cough* |
| 19:51.02 | brad | bzion is vaporware:P |
| 19:51.30 | alpha1-3 | vaporware hehe, that is Spanish or just cognate? :) |
| 19:51.30 | allejo | it's still under relatively active development! |
| 19:51.48 | blast007 | alpha1-3: no, I am sure who is the maintainer... I host the ducati site, so I know where the code comes from... |
| 19:52.18 | blast007 | alpha1-3: and I gave you the link to the ducati fork in ##ducleague |
| 19:52.56 | alpha1-3 | ow my client didn't show me the colored notice, sorry |
| 19:53.35 | alpha1-3 | you are everywhere, blast! :D |
| 19:53.52 | alpha1-3 | kind of your part, though! |
| 19:54.14 | blast007 | why do you have multiple clients running? |
| 19:54.28 | allejo | blast is omnipresent |
| 19:55.24 | blast007 | alpha1-3: you can connect to multiple channels from a single IRC client/connection as long as they're on the same network |
| 19:55.30 | alpha1-3 | I have 1 client, but 2 connections, I guess. cause I divided BZ channels in 2 groups. |
| 19:56.21 | alpha1-3 | anyways, it should notice me with colored tabs when there are new msgs, I must have changed something... |
| 19:58.36 | alpha1-3 | it is weird, didn't change anything about it. It must be cause of 2 connections then |
| 19:59.12 | alpha1-3 | will try adding other server |
| 20:05.32 | *** part/#bzflag alpha1-3 (~alpha1-2@host31.190-224-22.telecom.net.ar) |
| 20:18.25 | *** join/#bzflag alpha1-2 (~alpha1-2@host31.190-224-22.telecom.net.ar) |
| 20:27.04 | alpha1-2 | ohh I got it! every tab has its own menu (right button) then you can enable/disable each individual notification, apart of the general configuration, I forgot! |
| 20:27.37 | alpha1-2 | KDE/Konversation is very complete |
| 20:27.47 | alpha1-2 | are* |
| 21:19.22 | *** join/#bzflag JeffM (~JeffM@2605:e000:7d02:c700:311c:d5e9:fc96:ca12) |
| 21:19.35 | *** join/#bzflag sirquine (~quine@2601:1:8d80:9d3:226:bbff:fe19:5689) |
| 21:36.12 | *** join/#bzflag khonkhortisan_ (~kyle@2601:8:8600:97f:4a5b:39ff:fe94:be23) |
| 22:00.25 | *** join/#bzflag Snake12534 (635cd32e@gateway/web/freenode/ip.99.92.211.46) |
| 22:06.39 | *** join/#bzflag JeffM (~JeffM@2605:e000:7d02:c700:311c:d5e9:fc96:ca12) |
| 23:31.53 | *** join/#bzflag JeffM (~JeffM@2605:e000:7d02:c700:311c:d5e9:fc96:ca12) |