| 00:17:38 | captain_proton | kicks vogon_jeltz |
| 00:17:47 | vogon_jeltz | ow |
| 00:18:04 | captain_proton | whatever happened to SDL? |
| 00:18:17 | vogon_jeltz | I have it |
| 00:18:29 | vogon_jeltz | just not the res switching |
| 00:18:32 | captain_proton | does it work? |
| 00:18:38 | vogon_jeltz | yeah, except for res switching |
| 00:18:57 | captain_proton | well... |
| 00:18:59 | vogon_jeltz | it only runs at 1024x768x32 |
| 00:19:02 | captain_proton | finish it! |
| 00:19:05 | vogon_jeltz | hehe |
| 00:19:17 | vogon_jeltz | I will as soon as I get this authentication thing working |
| 00:19:31 | captain_proton | authentication? |
| 00:19:45 | vogon_jeltz | yeah, for my MMORPG server |
| 00:19:59 | vogon_jeltz | I just need to rough something in |
| 00:52:34 | scanline | is back (gone 01:36:57) |
| 02:45:38 | MrApathyCream | any new dev goin' on? anyone? |
| 02:47:52 | MrApathyCream | wonders off |
| 05:07:59 | captain_proton | damn this channel is boring =| |
| 05:25:13 | captain_proton | new wiki stuff? |
| 05:25:29 | BZFlag | just support for shorter urls. |
| 05:25:50 | captain_proton | ahh |
| 05:27:56 | captain_proton | can't decide on a topic? |
| 05:31:03 | BZFlag | heh, just a few different edits. |
| 05:51:46 | captain_proton | hrms |
| 07:05:24 | | I haven't seen '*', MrApathyCream |
| 07:05:24 | MrApathyCream | ibot seen *? |
| 07:05:54 | | I haven't seen 'my_ass', vogon_jeltz |
| 07:05:54 | vogon_jeltz | ibot, seen my_ass? |
| 07:06:02 | captain_proton | pokes MrApathyCream |
| 07:06:35 | MrApathyCream | dev stopped now? |
| 07:06:41 | MrApathyCream | sheesh |
| 07:06:48 | captain_proton | apparently =| |
| 07:06:59 | vogon_jeltz | I'll drop in my Tcl code soon |
| 07:07:17 | vogon_jeltz | and SDL |
| 07:07:17 | vogon_jeltz | and HIJKL |
| 07:07:17 | captain_proton | i think once the obstacle stuff comes in things will pick up again |
| 07:07:26 | captain_proton | vogon_jeltz: what does your Tcl code do? |
| 07:07:56 | MrApathyCream | obstacle == crs? |
| 07:08:14 | vogon_jeltz | captain_proton: it provides a nice generic wrapper for Tcl so far |
| 07:08:21 | vogon_jeltz | captain_proton: I'll add in some hooks soon |
| 07:08:38 | MrApathyCream | again, i back up captain_proton question... what does tcl do? |
| 07:08:49 | captain_proton | MrApathyCream: yep |
| 07:09:04 | vogon_jeltz | MrApathyCream: heh. it'll provide enhanced bot support |
| 07:09:29 | vogon_jeltz | MrApathyCream: including bots that don't have to be recompiled when you modify their AI |
| 07:10:19 | vogon_jeltz | I plan to merge it into the server code |
| 07:10:30 | captain_proton | into the -server- ? |
| 07:10:31 | vogon_jeltz | so that you can run bots headless |
| 07:10:43 | vogon_jeltz | yes |
| 07:10:51 | MrApathyCream | does anyone really want bots? |
| 07:11:10 | MrApathyCream | i'd prefer tanks exploding myself :) |
| 07:11:11 | vogon_jeltz | alternately, I'll hack up a client with everything stubbed out and all control functions hooked into Tcl |
| 07:11:39 | vogon_jeltz | hehe |
| 07:12:37 | captain_proton | MrApathyCream: the original battlezone had these cool spaceships in it... |
| 07:17:53 | MrApathyCream | 2003 is almost here |
| 07:18:06 | vogon_jeltz | yeah, only 9 months away |
| 07:18:13 | vogon_jeltz | we better start preparing |
| 07:22:44 | MrApathyCream | 1.8 won't be done by then |
| 07:23:11 | captain_proton | how can you know? |
| 07:23:27 | vogon_jeltz | we haven't finished it in, what, 12 years? |
| 07:23:37 | captain_proton | haha |
| 07:23:51 | MrApathyCream | poor planning |
| 07:24:38 | captain_proton | well |
| 07:24:45 | MrApathyCream | Let's face it all this flexibility crap is cool and all, but no one really wanted it |
| 07:24:54 | captain_proton | feel free to do a traceability matrix for 1.8 if you want |
| 07:25:01 | captain_proton | raises his hand |
| 07:25:05 | captain_proton | I wanted it |
| 07:25:08 | MrApathyCream | bah |
| 07:25:12 | MrApathyCream | you wanted better lag |
| 07:25:20 | MrApathyCream | I know you did |
| 07:25:25 | captain_proton | that too |
| 07:25:31 | MrApathyCream | no ones lifted a dingleberry on that one |
| 07:25:48 | captain_proton | yes we have |
| 07:26:01 | MrApathyCream | bah |
| 07:26:06 | MrApathyCream | all talk, no action |
| 07:26:08 | captain_proton | what about packet combination? all-udp? |
| 07:26:22 | captain_proton | riker's working on combination right now |
| 07:26:34 | captain_proton | right BZFlag? |
| 07:26:39 | captain_proton | pokes |
| 07:27:56 | MrApathyCream | a subset of users want more amusing game play (either new flags, or new 'phenomena' or ...) |
| 07:28:44 | MrApathyCream | even the png stuff, no one really wanted it |
| 07:29:21 | MrApathyCream | that's why > 2003, imo |
| 07:29:36 | captain_proton | well... |
| 07:30:03 | captain_proton | i guess if we start getting delayed i might but some of this software engineering stuff to work |
| 07:58:20 | iLLf8d | hmm |
| 07:58:25 | iLLf8d | you guys married? |
| 07:58:34 | iLLf8d | apathy and his 2 wives heh |
| 07:58:35 | captain_proton | huh? |
| 07:58:51 | iLLf8d | you guys sound like a bf/gf fighting |
| 07:59:08 | MrApathyCream | heh |
| 07:59:16 | captain_proton | hugs MrApathyCream |
| 07:59:19 | iLLf8d | you know you wanted it, no I didn't heh |
| 07:59:20 | iLLf8d | n=P |
| 07:59:30 | iLLf8d | typos sheesh |
| 08:00:21 | iLLf8d | has a wishlist alot more flags, and better map functions like inverted pyramids, more teleporters and teleporters on the ground flag |
| 08:00:25 | iLLf8d | s/flag/flat |
| 08:00:55 | iLLf8d | or better yet a flag api |
| 08:01:19 | iLLf8d | cap had to kick someone yesterday |
| 08:01:21 | iLLf8d | had a cheat tank |
| 08:01:33 | Aldebaran | Hi, is there a special character that causes text to be not echoed? |
| 08:01:37 | iLLf8d | his sw was so big from the inside sq to the outter sq corner the sw got me heh |
| 08:01:46 | Aldebaran | number guy is at chardonney |
| 08:01:46 | iLLf8d | it was huge |
| 08:01:49 | BZFlag | captain_proton: working on it, yes. |
| 08:02:04 | BZFlag | I might leave the tcp stuff, but I will be combining packets. |
| 08:02:27 | BZFlag | note that 1.8 now uses one tcp and one udp port on both client and server. |
| 08:02:38 | BZFlag | the server port is specified on the command line. |
| 08:02:57 | BZFlag | the client gets a random tcp port and then uses the same port for the udp connect. |
| 08:13:46 | MrApathyCream | heh, i think there are more cheaters than 'straights' at digitaleclipse now |
| 08:14:10 | captain_proton | lol |
| 08:25:22 | iLLf8d | yup |
| 08:25:31 | iLLf8d | digital eclipse is bad so is chard |
| 08:25:52 | iLLf8d | hmm |
| 08:28:59 | MrApathyCream | wonders how affective packet combining will be without multithreaded server to stuff queues |
| 08:29:53 | captain_proton | how does the choice of multithreading vs. selection/polling affect packet combination? |
| 08:30:29 | iLLf8d | i'd think you'd have to run test to figure it out or look at a reference like that stevens book |
| 08:30:58 | captain_proton | true |
| 08:31:19 | iLLf8d | they've got a few perty tables in there that may apply |
| 08:32:08 | MrApathyCream | in order to combine packets, you need multiple packets. With a uni threaded model that means that you must 'stall' one packet to wait for another to join it |
| 08:32:13 | MrApathyCream | kind of self-defeating. |
| 08:32:29 | captain_proton | true |
| 08:32:44 | MrApathyCream | On the other hand, if each client has a thread, each thread can 'post' send requests to on clients thread at the same time |
| 08:32:55 | MrApathyCream | that clients thread can then immediately batch n number of requests |
| 08:33:08 | captain_proton | well |
| 08:33:21 | captain_proton | packet combination will increase latency on the earlier messages |
| 08:33:27 | captain_proton | but reduce the total network traffic |
| 08:33:42 | captain_proton | all in all i'm hoping for it to provide an increase in playability |
| 08:33:43 | MrApathyCream | yes, that is true. |
| 08:34:08 | captain_proton | the server has to send out messages anyways |
| 08:34:17 | captain_proton | i don't think it will matter if there's a buffer in the middle |
| 08:34:26 | MrApathyCream | I'm a believer in multithreaded servers, though. especially when most threads are just sitting waiting on sockets |
| 08:34:51 | MrApathyCream | Think about player update. Each player broadcasts to all other players. |
| 08:35:21 | MrApathyCream | So n threads receive n player updates at the same time. Each replicates and drops this message in each other threads queue |
| 08:35:25 | BZFlag | why have multiple threads waiting on sockets when one will do? |
| 08:35:38 | MrApathyCream | now each thread has n player updates in the queue immediately available to batch |
| 08:35:41 | BZFlag | specially since there is only one listening udp socket anyway. |
| 08:36:58 | MrApathyCream | Yes, if you only have one udp socket, there's not as much of a need for multithreading. |
| 08:37:16 | MrApathyCream | on the receive side, anyway. |
| 08:37:34 | MrApathyCream | on the send side it still is useful. |
| 08:37:57 | captain_proton | yeah i was actually considering that |
| 08:38:11 | captain_proton | threading the client that is |
| 08:38:12 | MrApathyCream | i personally would have n udp sockets |
| 08:38:23 | vogon_jeltz | is away: TV |
| 08:38:24 | MrApathyCream | i'm talking on the server captain_proton |
| 08:38:33 | BZFlag | knows of no massive multiplayer online games that use threading. |
| 08:39:09 | MrApathyCream | Perhaps, but why is that. |
| 08:39:24 | MrApathyCream | I know of no, web/app servers that are unithreaded |
| 08:39:47 | BZFlag | cause it's not a real solution. it just moves it up the chain to some kind of semiphore system on the queues. |
| 08:40:11 | BZFlag | apache counts as threaded in your book? |
| 08:40:11 | captain_proton | and linux spinlocks suck |
| 08:40:18 | MrApathyCream | semaphores are much quicker than socket polling |
| 08:40:42 | captain_proton | BZFlag: apache 2.0 does ;) |
| 08:40:52 | BZFlag | MrApathyCream: you have not removed the socket polling. just added the semaphores |
| 08:41:18 | MrApathyCream | You don't poll sockets, you just read. one thread per socket. thread just does |
| 08:41:19 | MrApathyCream | { |
| 08:41:22 | MrApathyCream | read(); |
| 08:41:24 | MrApathyCream | process(); |
| 08:41:27 | MrApathyCream | } while (true); |
| 08:41:28 | captain_proton | MrApathyCream: a blocking read() essentially continually polls |
| 08:41:43 | BZFlag | nods at captain_proton |
| 08:41:44 | MrApathyCream | yes but with no processor impact |
| 08:41:58 | MrApathyCream | with a select, you then have to loop through each socket and handle it |
| 08:42:01 | BZFlag | same impact as a select() |
| 08:42:05 | MrApathyCream | sockets at the end of the list are big time blocked |
| 08:42:17 | captain_proton | you have the processor load anywhere |
| 08:42:33 | BZFlag | select() tells you which sockets have data. |
| 08:42:34 | captain_proton | if its not in the poll loop then you have it in the loop timing packet sends |
| 08:42:50 | MrApathyCream | yes, lets say 10 sockets have data. Socket 10 stalls until 1-9 are processed. |
| 08:43:28 | captain_proton | if its threaded you have the same problem |
| 08:43:33 | BZFlag | if you process select() returns quickly (a big if) then select() will normally just have one handle hit, and everything happens fast. |
| 08:43:36 | MrApathyCream | this causes slow connections to drag even slower being starved by fast connections. |
| 08:43:41 | captain_proton | you increase response time but decrease throughput |
| 08:44:02 | BZFlag | 10 sockets will never have data if you are processing fast enough. |
| 08:44:18 | MrApathyCream | if a slow connection has it's own thread, you are not penalizing it with faster connections |
| 08:44:39 | MrApathyCream | it doesn't have to compete with faster connections X number of packets per slow connection |
| 08:44:56 | captain_proton | MrApathyCream: uhm |
| 08:45:17 | captain_proton | MrApathyCream: the slow connection is transparent to the select |
| 08:45:28 | captain_proton | by the time select returns with data, the data is already there |
| 08:45:37 | MrApathyCream | lets say you have 10 fast connections and 1 slow one. |
| 08:45:45 | captain_proton | ok |
| 08:46:06 | MrApathyCream | The slow client, not only has to compete with 10 clients. but 10 clients X the number of packets each can send in the time it takes the slow client to send 1 packet |
| 08:46:31 | BZFlag | either the os has delivered the slow connections packet or it has not. |
| 08:46:34 | MrApathyCream | if each has it's own thread. once the data has gotten to the server, the slow connection is on even footing |
| 08:46:41 | BZFlag | where's the compete? |
| 08:46:58 | MrApathyCream | select says 10 sockets have data. |
| 08:47:16 | MrApathyCream | 9 have multiple packets, one has 1 packet. now the one packet has to wait for 9 x multiple packets |
| 08:47:31 | MrApathyCream | because processing is serialized |
| 08:47:31 | BZFlag | your arguement assumes the server is tanking longer to process a packet than the time between packets. |
| 08:47:48 | BZFlag | if that is realy true, then the server will lag no matter what you do. |
| 08:48:17 | BZFlag | fix the server so it can process as fast as it can read, and all (well, most all) select()s will only return on one handle. |
| 08:48:45 | MrApathyCream | Just curious, really don't know, how many games have a server? |
| 08:48:46 | iLL | BZFlag: you have any idea why I have issues running client and server on the same machine? seems I can't connect to 127.0.0.1 from the client either is that normal? |
| 08:48:56 | BZFlag | this can not be done for httpd servers if they support cgi, hence the multi{thread|process} design. |
| 08:49:21 | iLLf8d | hmm |
| 08:49:32 | BZFlag | MrApathyCream: online games (ultima, subspace, quake, etc) all do. |
| 08:49:56 | MrApathyCream | for more than discovery? |
| 08:50:00 | | version is gay |
| 08:50:00 | BZFlag | iLLf8d: version? |
| 08:50:13 | BZFlag | ibor forget version |
| 08:50:15 | iLLf8d | e4 and e5 |
| 08:50:18 | | BZFlag: I forgot version |
| 08:50:18 | BZFlag | ibot forget version |
| 08:50:25 | iLLf8d | one i'm invisible |
| 08:50:34 | iLLf8d | and the other whenever i'm killed everyone gets booted |
| 08:50:38 | BZFlag | iLLf8d: try e5 in cvs at present. I just changed some port issues. |
| 08:50:44 | iLLf8d | hmm |
| 08:50:51 | iLLf8d | will do |
| 08:51:20 | BZFlag | I assume you have no trouble with 1.8 cause of the rework. |
| 08:51:24 | MrApathyCream | In anycase unithreaded packet combining causes lag of initial packets |
| 08:51:39 | captain_proton | well |
| 08:51:41 | BZFlag | as would threaded combining. |
| 08:51:56 | MrApathyCream | insignificant |
| 08:52:04 | BZFlag | same delay. |
| 08:52:04 | captain_proton | its the same lag |
| 08:52:34 | MrApathyCream | howdya figure? |
| 08:52:47 | BZFlag | either you write a set of msgs or you don't |
| 08:52:56 | iLLf8d | I haven't tried 1.8 |
| 08:52:59 | iLLf8d | will try it to see |
| 08:53:03 | BZFlag | the earlier ones are (slightly) delayed |
| 08:53:14 | iLLf8d | I've used the client but never the server |
| 08:53:33 | MrApathyCream | Hm, The server sender thread is busy sending data. |
| 08:53:39 | iLLf8d | I gotta restart with this box as a gateway so I can dump some tcp to see whats boning my connection |
| 08:53:42 | MrApathyCream | In the meantime n threads are filling it's outbound buffer |
| 08:53:44 | iLLf8d | I bbl =) |
| 08:53:56 | MrApathyCream | When the sender thread is done, it immediately has n messages to send |
| 08:54:11 | MrApathyCream | In uni, the sender code sends a message |
| 08:54:11 | BZFlag | MrApathyCream: _never_ busy sending or receiving. that's what non-blocking is all about. |
| 08:54:19 | MrApathyCream | when it is done, no messages are there, it has to go read 1 |
| 08:54:33 | MrApathyCream | still there are not mulitple messages, so again he lags that one |
| 08:54:41 | MrApathyCream | now a second comes in, now he can combine |
| 08:55:06 | MrApathyCream | Still you are busy, posting a write |
| 08:55:16 | BZFlag | never busy posting a write. |
| 08:55:37 | BZFlag | it's the time taken for one call/return and noting more. |
| 08:55:42 | MrApathyCream | the send() method takes some time, even if you don't wait for it to complete |
| 08:55:43 | BZFlag | er nothing. |
| 08:56:02 | captain_proton | MrApathyCream: so how does adding a semaphore help with that? |
| 08:56:08 | BZFlag | does not take time. just the syscall over head. _always_ returns instantly. |
| 08:56:17 | MrApathyCream | right, but it still is serialized |
| 08:56:37 | BZFlag | unless you have multiple nics it's all serialized. |
| 08:56:57 | MrApathyCream | i mean the code path |
| 08:57:05 | BZFlag | so do I |
| 08:57:16 | MrApathyCream | you will always lag n-1 messages |
| 08:57:33 | MrApathyCream | until you are satisfied that n is the proper combining number |
| 08:57:46 | MrApathyCream | <or timeout> |
| 08:57:51 | BZFlag | not true. we packet combining, select() microsleeps till the nexxt due packet send on any handle. |
| 08:58:04 | BZFlag | right, timeout. |
| 08:58:09 | BZFlag | same is tru of threads. |
| 08:58:49 | MrApathyCream | i wouldn't I'd just send what was present in the out buffer |
| 08:58:59 | MrApathyCream | this buffer can be filled by n threads at 'the same time' |
| 08:59:01 | BZFlag | then you are not combining, are you? |
| 08:59:18 | captain_proton | MrApathyCream: nothing is done at the same time |
| 08:59:24 | MrApathyCream | yeah, yeah |
| 08:59:26 | MrApathyCream | semantics |
| 08:59:29 | captain_proton | it just uses semaphores to make it seem so |
| 08:59:44 | BZFlag | so one thread enters a packet and you don't see that? you miss multiple additions tou your cue? |
| 09:00:11 | MrApathyCream | you have n receive threads, and n send threads |
| 09:00:15 | MrApathyCream | each receive thread does |
| 09:00:15 | MrApathyCream | { |
| 09:00:17 | MrApathyCream | read() |
| 09:00:17 | BZFlag | what exactly are you doing between each of the msg additions such that when you do get around to reading there are multiple packets? |
| 09:00:42 | MrApathyCream | figureoutwheretosend() |
| 09:00:48 | MrApathyCream | posttooutqueue() |
| 09:00:49 | MrApathyCream | } |
| 09:00:55 | MrApathyCream | each send queue does |
| 09:00:55 | MrApathyCream | { |
| 09:01:05 | MrApathyCream | collect_msg_inq() |
| 09:01:08 | MrApathyCream | sendthem(); |
| 09:01:11 | MrApathyCream | } |
| 09:01:18 | MrApathyCream | of course protected by sems, etc |
| 09:01:21 | BZFlag | you forgot sleeptilltheoutqueuesemaphoreisavailable() |
| 09:01:41 | captain_proton | so you have 2n+1 threads where n is the number of connections? |
| 09:01:57 | MrApathyCream | n is the number of players |
| 09:02:09 | MrApathyCream | 100 mostly idle threads is no problem |
| 09:02:18 | captain_proton | thats a lot of semaphores |
| 09:02:29 | MrApathyCream | big whopdi do |
| 09:03:05 | captain_proton | so - you would replace serialization with a large spin queue? |
| 09:03:09 | BZFlag | 1 efficient process that select()s would clearly use less resources. |
| 09:03:33 | MrApathyCream | thats true. I don't really care about that. I want speed |
| 09:03:42 | BZFlag | captain_proton: 2n+1 spin queues |
| 09:03:59 | captain_proton | BZFlag: you have a single spin queue for the NIC |
| 09:04:26 | captain_proton | but yes, you also have semaphores for the queues |
| 09:04:28 | BZFlag | exactly. the same queue that the hardware itself requires. |
| 09:04:29 | MrApathyCream | actually just n spin queues |
| 09:04:48 | MrApathyCream | you only queue output data |
| 09:04:57 | BZFlag | ah, true if you only block check write queues. |
| 09:05:12 | captain_proton | you also have blocking reads |
| 09:05:28 | BZFlag | the point is that the OS already has a spin lock for the hardware. |
| 09:05:32 | MrApathyCream | yup, blocking reads == mostly idle threads |
| 09:05:49 | captain_proton | what good is an idle thread? |
| 09:05:51 | BZFlag | efficient select() usage allows you to use that spinlock directly. |
| 09:06:32 | MrApathyCream | still your lagging messages if you combine |
| 09:06:43 | captain_proton | yep |
| 09:06:45 | BZFlag | captain_proton: it eats memory, slows your compiles. good enough? ;-) |
| 09:06:54 | captain_proton | happens regardless of threading |
| 09:07:00 | captain_proton | BZFlag: yep - lets do it! |
| 09:07:27 | BZFlag | MrApathyCream: as you have just shown, so does a threaded method if it actually ever combines packets. |
| 09:07:52 | MrApathyCream | I missed that part ;) |
| 09:08:29 | MrApathyCream | if a == b and c == d, then a==d, wait, ... ? |
| 09:08:30 | captain_proton | no matter how you combine, message(s) will have to wait |
| 09:08:32 | BZFlag | if collect_msg_inq() ever finds multiple msgs, then it has lagged by definition. |
| 09:08:57 | MrApathyCream | but it lags for the length of time of an async write |
| 09:09:10 | MrApathyCream | as opposed to a select-read-process-write |
| 09:09:13 | BZFlag | and select() can do the same. |
| 09:10:07 | MrApathyCream | ok to be fair multi lags for sem-test async write |
| 09:10:18 | MrApathyCream | better than select, read, process, write |
| 09:10:40 | BZFlag | select() returns, do the reads/writes, select() for no-time, flush, select() for microtime. |
| 09:11:34 | BZFlag | if you ignore select on write queues... then that's: |
| 09:11:37 | iLLf8d | hmm anyone know about dhcp? |
| 09:12:21 | captain_proton | what about it? |
| 09:12:25 | iLLf8d | hmm |
| 09:12:28 | iLLf8d | 50 second lag time |
| 09:12:29 | iLLf8d | wtf |
| 09:12:31 | BZFlag | select(small), read, select(0), read if any, write, select(small). |
| 09:13:16 | iLLf8d | 01:08:52.936929 arp who-has sc-66-74-71-49.socal.rr.com tell 66.74.64.1 |
| 09:13:16 | iLLf8d | 01:08:52.990342 arp who-has sc-66-74-70-105.socal.rr.com tell 66.74.64.1 |
| 09:13:24 | iLLf8d | I'm getting a ton of traffic like that |
| 09:13:34 | iLLf8d | I take it that its the dhcp server looking for a free ip |
| 09:13:39 | iLLf8d | to connect someone else? |
| 09:13:55 | captain_proton | the dhcp server should have a local cache |
| 09:14:02 | captain_proton | but it could be |
| 09:14:14 | BZFlag | simplify to select(next due), read, write(any due) and adjust due (to perhaps 0) |
| 09:14:24 | captain_proton | also could be a multihomed LAN |
| 09:14:27 | iLLf8d | I'm wondering if my cable problems are my router not responding to queries about my current ip |
| 09:14:39 | iLLf8d | that way the server tries to give out my ip and its already in use |
| 09:14:41 | iLLf8d | causing the hiccup |
| 09:14:56 | captain_proton | could be |
| 09:14:59 | BZFlag | iLLf8d: that's on your cable modem, yes? |
| 09:14:59 | iLLf8d | the ip doesn't change its static |
| 09:15:05 | iLLf8d | uhm... |
| 09:15:08 | BZFlag | arps are not dhcp requests. |
| 09:15:12 | MrApathyCream | heads off to bed |
| 09:15:19 | iLLf8d | thats on my NIC |
| 09:15:26 | iLLf8d | I have it connected to my cablemodem |
| 09:15:27 | captain_proton | wow |
| 09:15:30 | BZFlag | which is hooked to your cable modem? |
| 09:15:31 | iLLf8d | I took the router outta the line |
| 09:15:33 | iLLf8d | yeah |
| 09:15:33 | captain_proton | apathy and bed in the same sentence? |
| 09:15:53 | BZFlag | so what's the problem? that's normal ethernet traffic. |
| 09:15:55 | iLLf8d | 01:09:08.189157 user-0c8gjok.cable.mindspring.com.32811 > ns3.mindspring.com.domain: 16577+ PTR? 49.71.74.66.in-addr.arpa. (42) (DF) |
| 09:15:55 | iLLf8d | 01:09:08.341528 ns3.mindspring.com.domain > user-0c8gjok.cable.mindspring.com.32811: 16577* 1/2/2 PTR[|domain] |
| 09:15:55 | iLLf8d | 01:09:08.342332 user-0c8gjok.cable.mindspring.com.32811 > ns1.mindspring.com.domain: 16578+ PTR? 36.73.74.66.in-addr.arpa. (42) (DF) |
| 09:16:07 | iLLf8d | those are a few others I get |
| 09:16:13 | BZFlag | that's normal dns lookups |
| 09:16:21 | iLLf8d | it seems that I have times when it doesn't respond |
| 09:16:38 | iLLf8d | my router isn't renewing the lease (at that moment) but all traffic stops |
| 09:16:46 | iLLf8d | and the ip remains the same |
| 09:16:50 | BZFlag | no traffic at all when it does not reply? |
| 09:17:02 | iLLf8d | the hesitation forces bzflag to not reply and my irc to disconnect |
| 09:17:03 | BZFlag | use -n on tcpdump to eliminate the dns delays. |
| 09:17:21 | iLLf8d | well I'm not positive about that thats why I took the router out to watch tcpdump |
| 09:17:30 | BZFlag | use tcpdump -n |
| 09:17:50 | iLLf8d | woa |
| 09:17:51 | BZFlag | else tcpdump will hang waiting for dns replies. |
| 09:17:56 | iLLf8d | that much shit goes by |
| 09:18:07 | iLLf8d | what are all the arps from? |
| 09:18:28 | iLLf8d | seems like its the same ones over and over |
| 09:18:50 | BZFlag | every eternet device connected to every modem on the same cable line you are on. |
| 09:19:18 | iLLf8d | there was a bootp |
| 09:19:21 | iLLf8d | thats a new one |
| 09:19:43 | BZFlag | bootpc/bootps are dhcp requests/replies |
| 09:20:15 | iLLf8d | hmm you have any idea what might be causing my issue or a good way to troubleshoot it? |
| 09:20:20 | BZFlag | use tcpdump -v -v -v -s 1500 port bootps or port bootpc to just see tose. |
| 09:20:29 | BZFlag | er those. |
| 09:20:43 | iLLf8d | I just got the cable about 1 month ago |
| 09:20:49 | iLLf8d | been lazy about figuring it out |
| 09:20:54 | iLLf8d | gotta see where the issue is |
| 09:21:15 | BZFlag | first see if traffic stops completely, or perhaps is full from traffic of another user. |
| 09:21:23 | iLLf8d | yeah... |
| 09:21:24 | iLLf8d | uhm |
| 09:21:29 | iLLf8d | how big will my logs get? |
| 09:21:37 | BZFlag | if it stops, then it could be line quality |
| 09:21:39 | iLLf8d | ie it happens about 6 times a day or so |
| 09:21:58 | iLLf8d | so if I dump to a log till it happens won't it be megs or gigs in size? |
| 09:22:12 | BZFlag | depends on the ammount of traffic on the line. Large, I'd say. |
| 09:22:26 | iLLf8d | A good way to check is to run ftp or bzflag |
| 09:22:37 | iLLf8d | they both take a dump but they'd generate alot of traffic too |
| 09:22:38 | BZFlag | or ping -f ;-) |
| 09:23:06 | iLLf8d | I got about 19gig free on my archive path |
| 09:23:17 | iLLf8d | maybe I can use that for logging and just play bzflag a while |
| 09:23:23 | iLLf8d | till it happens |
| 09:23:43 | iLLf8d | what would you suggest I ping if I do? |
| 09:23:51 | iLLf8d | and can I set interval on the flood heh |
| 09:23:57 | captain_proton | ping -f localhost |
| 09:24:11 | captain_proton | grins |
| 09:24:14 | iLLf8d | thanks heh |
| 09:24:19 | captain_proton | if you do that on a windows box it freezes completely |
| 09:24:25 | iLLf8d | pings protons head |
| 09:24:40 | iLLf8d | uh oh no response |
| 09:24:42 | iLLf8d | heh |
| 09:24:54 | captain_proton | haha |
| 09:24:55 | iLLf8d | hmm |
| 09:25:05 | iLLf8d | I guess i'l bz till it drops then kill the log |
| 09:25:12 | iLLf8d | hopefully it won't fill the whole drive heh |
| 09:26:12 | iLLf8d | ok gonna game bbl |
| 09:27:23 | BZFlag | ping one of those ips that keep arp'ing. ;-) |
| 09:27:34 | captain_proton | heh |
| 10:10:40 | vogon_jeltz | is back (gone 01:32:17) |
| 12:18:45 | iLLf8d | hrms |
| 12:57:48 | vogon_jeltz | is away: whatever |
| 13:36:53 | Chestal | re |
| 13:58:04 | Chestal | hi Cobra |
| 14:00:34 | CobraA1 | hello |
| 14:01:32 | CobraA1 | gotta go |
| 14:01:34 | Chestal | I think I'm goign to take a stroll, sun is shining beautifully, will be back in an hour |
| 14:01:55 | CobraA1 | k. |
| 15:08:18 | CobraA1 | I've only got 10 min. |
| 15:08:47 | Chestal | I'm back |
| 15:09:02 | Chestal | argh, theseshoes are not made for walking, my feet hurt |
| 15:11:03 | CobraA1 | I'll be asking some students in my CIS class if they have (or can get) Debian. |
| 15:13:27 | Chestal | yep, that's a good idea. Maybe they can help when there are problems, too |
| 15:14:01 | CobraA1 | You say it's easily updateable online, right? |
| 15:16:59 | CobraA1 | in any case, I'm going to class now. TTYL. |
| 22:14:44 | miraage | hmm |
| 22:14:48 | miraage | hey, anyone around? |
| 22:15:42 | miraage | im not getting textures |
| 22:15:49 | Chestal | hi |
| 22:15:54 | Chestal | which version? |
| 22:43:08 | miraage | nevermind |
| 22:43:16 | miraage | im just stupid... the default option is no texturing |
| 22:52:05 | Chestal | yep |
| 23:38:29 | Chestal | quiet here today |