Subj : Another suggestion.... To : Deuce From : Time Warrior Date : Mon May 30 2005 09:18 pm From Newsgroup: alt.bbs.synchronet To: Deuce Re: Another suggestion.... By: Deuce to Angus Mcleod on Tue May 31 2005 12:15 am > To: Angus Mcleod > Re: Another suggestion.... By: Angus Mcleod to Deuce on Mon May 30 > 2005 18:40:00 > > > > Well whatever you want to call it, i'm sure theres a way. Maybe som > > > > like: > > > > Slow defined ANSI screens to display at: ##% (i.e - 10% of normal, > > > > normal, 5% of normal) and the sysop can just mess with the %age num > > > > it looks like it's going at the correct speed. > > > Would you like me to bore you with teh technical details of why it's n > > > possible? > > Bore me! Bore me! But first, go and REEEEEED the post from TW so you ca > > UNNERSTAAAAAAN what it is he's talking about. > I'll start with the simplest issue and see if you still want more... > TCP is a packets based protocol. That is to say that data is sent in discre > groupes of bytes which arrive at effectively the same instant. Generally > speaking, you want to send that largest possible packets. In general, that' > 1500 bytes. > Synchronet on the other hand will by default attempt to send ni 1024 bytes > groups. > All 1024 bytes *will* arrive at the other end at EXACTLY the same time (unle > something causes a packet to be split, a different issue I won't address) > Because if this there is exactly zero time between one char and the next... > there is an infinite cps rate per packet (generally as close to 1024 as > Synchronet can make it) > If Synchronet were to use a single-byte packets size (And you CAN tell it to > this currently if you are insane) then it will take *at least* fourty times > much bandwidth to send a single ANSI. This is because every TCP packet has > least 40 bytes of header information. So, pretending you have a 128kbps > upsteam (common) your maximum possible transmit speed using a non-infinite c > rate would be 409cps which is comparible to a 4096bps modem. This is far > slower than anyone would want their ANSIs displayed... and if you have more > than one caller, this bandwidth is shared between them. > So, due to the bursty nature of TCP traffic, ANSI animations will be either > *very* high bandwidth, or choppy. For large screens, it's either hery high > bandwidth, or you get a number of lines (Probobly around 3-10 depending on j > how ANSIfied they are) at a time, then a pause, then the 3-10 more etc. > that is merely problem number one. > More issues I can bore you with are round trip time, fragmenting packets, > latency, and bandwidth sharing between multiple connections (to *anything* v > your internet connection)/ > For those who want to experience a small taste of the joy of one-byte packet > in the [BBS] section of your .ini file, modify OutbufHighwaterMark=1024 to > OutbufHighwaterMark=1 And change the value of OutbufDrainTimeout > to 1 also. Well then the only solution I could think of would have absolutely nothing to do with Synchronet. You'd need an ansi editor that could set the redraw speed to a much more insanely slow rate than current editors allow. I think thedraw allows a max speed of "100" ... so solve this problem (and taking into account everyone has different speed connections) a top "slow" speed of 99999 (or something that outrageous) might have to be supported in an editor of some sort. So this clearly falls within the realms of a third party editor and it's nothing Synchronet itself could handle at this time. -- .---------------------------------------------------------------. | [TiME WaRRiOR] aka [Dave Kelso] AIM: Twar782 | +o Malkavia BBS | | www : synchsupport.net - malkaviabbs.com - xpresit.net | | www$: josephsjewelersonline.com - preferedinsurance.com | | @: time.warrior@malkaviabbs. com | \______________________________________________________________/ --- Synchronet 3.12a-Win32 NewsLink 1.76 * Malkavia - Chicago, IL - telnet://malkaviabbs.com --- Synchronet 3.12b-Win32 NewsLink 1.83 .