Missing characters on throughput
#1
I've been running a BBS using my Wimodem232 v1 for a while now.  (thebrewery.servebeer.com:6400)

Some telnet clients done seem to get along with the Wimodem232.
It manifests itself by missing characters.
For instance:
  _______________________________________________________________________
 |                                                                       |
 |________________________ THE BREWERY  Main Menu _______________________|
 |                                                                       |
 |  [Q] Quickscan Message Bases       |  [B]  Link to Bulletin System    |
 |                                    |                                  |
 |  [A]  Borderline Quotes            |  [C]  Request Chat with Sysop    |
 |  [F]  Leave Feedback to Sysops     |  [G]  Goodbym             |
 |  [N]  Board / System News updates  |  [S]  Your system statistics     |
 |  [V]  View log of daily callers    |  [W]  Visit The Wall             |
 |____________________________________|__________________________________|
 |                                    |                                  |
 |  [1]  File Transfer Area           |  [2]  Text Files, Games & Misc   |
 |  [3]  RPG Launcher (offline)       |  [4]  User U
There's a new RAMWorks III card available at Reactive Micro.  Get yours today.


[MAIN ROOM]
[059:00 Left][Time is: 12:52:00 PM][?=Help]:

Notice how the main menu hasn't completely rendered out and there are missing characters midway near the "goodbye"?
I am leaning to the fault being at the Wimodem - it seems to buffer data and then barf it out all at once - the menu does not stream smoothly.  
When the user enters "?" to display the menu there is a pause, and then the menu blasts over the telnet connection at super high speed.
Could it be that characters may be getting lost somewhere along the line? 
Is there a fix for that?
Thanks
Henry
Reply
#2
Are you using hardware flow control?  What you show is very common when the WiModem232 is sending data faster than the computer can receive it, so flow control is necessary.
Reply
#3
I first thought the same thing. I can't use hardware flow control on the Wimodem because I need DTR and DSR (can't have DTR/DSR and CTS/RTS together on v1).
But I don't think this is the case here because the client I'm using in the example I posted was a telnet connected terminal program on my Mac. I don't think the server (the BBS connected to the Wimodem) is the issue because the connection speed there is 9600 baud - but because of whatever buffering and batch sending is happening, data seems to be getting lost between the Wimodem and the remote client.

The best performance I have gotten while logging in remotely to the BBS is using Ftelnet (http://embed-v2.ftelnet.ca) which is a browser embedded telnet client with terminal emulation (it has very few errors), but the example I posted was with a telnet terminal emulator called Zok (https://www.emtec.com/zoc/)

When I use real hardware - another Apple II with another internet connected "modem" (not a Wimodem) I get occasional blips. Using software flow control - xon/xoff doesn't seem to help - perhaps the other "modem" doesn't buffer incoming data sufficiently?

In any case, I only seem to have this issue connecting with my Wimodem enabled BBS - other BBSes (I imagine they're connected with some sort of tcpser implementation) don't seem to blip on my end.

Henry
Reply
#4
You can likely never use any baud rate above 2400 baud without hardware flow control on any 8 bit machines.  I see mass dropped bytes on Commodore 64's without the hardware flow control enabled.

What computer are you using that you see this?

Since you are running a BBS using the WiModem232, I can swap your v1 for v2.  That would give you RTS/CTS and DTR/DSR capability at the same time.  The only possible way to actually lose data is that it is never sent or there is a buffer over-run due to not having flow control.
Reply
#5
This is the thing, though, Jim.

The display on that screen above is not from an 8-bit computer. It is from Zok - a telnet enabled terminal program that is running on my modern Mac.

I could understand if it were on another 8 bit computer, but it's not. Anyway the Apple //e and IIc doesn't typically have any issues sending or receiving at 9600 baud even without any flow control at all.
Reply
#6
Have you tried a different telnet program? I have tried plenty of different PC telnet programs and some work and some drop characters like you have shown without flow control enabled. I thought you were using an 8 bit machine. Smile

My Apple II+ w/SCC, Apple IIc (actually a Laser 128), and my Apple IIGS all require flow control. The Laser and IIGS use DTR/DSR as flow control with their special cable. The SCC uses RTS/CTS. Without flow control, I get dropped characters at 9600 baud with all 3 machines.
Reply
#7
I've got a V1 WiModem232 and have done quite a bit of programming for a telnet client on an 8 bit computer. I too at times was dropping characters, and there are a number of times I was scratching my head trying to figure out why.

it all really depends upon the quality of the code in the telnet client. If ANSI is being displayed, then there is a lot more code involved than just putting up a character on the screen. There is also the issue of whether the client is properly enabling flow control with the hardware. On the computers I deal with, there are 3 different types of RS232's. At the hardware level, that interface is handled differently.

Besides ANSI and needing to make sure the serial interface was going on, there were 2 other factors I had to deal with. Unless you have hardware scrolling with your video, on my system I have to read what is on the screen and rewrite the screen offset by width of the screen's width to move the screen up one line. There are various tricks one can use to speed up that aspect if you simultaneously buffer text in CPU rather than do a video read/video write, you are just doing a CPU to Video write. You can also use multiple (40 in my case), multiple video write statements in a row before decrementing a loop counter.

Finally, when I thought there was still an issue, it turned out I had a buffer size issue. I run a BBS (9640news.ddns.net:9640) and there is one point when one looks for new files, it checks each category. Well, the BBS can run really fast and I have over 200 areas, and the telnet client was grabbing all the characters, however I had enough bytes coming in and I was overwriting my ~12K buffer loop. Never an issue with a BBS that had but a couple of thousand bytes coming in, but when I hit a large amount running at 38,400 baud, it did not take long to loop.

Not knowing your clients, I would investigate the size of the receive buffer as that may be the only thing you can personally control in the client besides enabling hardware control if you are wired up properly for it.

My 2 cents.
Reply
#8
Interesting.

My concern stems from the fact that at 9600 baud my Apple IIe running Proterm never drops a character with any BBS I call except on my own BBS that runs a Wimodem232.

All the other boards are hooked up via some sort of TCPSER variation.

What I noticed is that when I remotely enter a command that causes a large-ish amount of data to flow (like displaying a menu, for instance)
there is a pause followed by a large influx of characters, some of which are dropped. It's as if the Wimodem buffers outgoing data and then sends it all at once rather than streaming it smoothly.
This was the nature of my original question.

If it can be solved on the client side via flow control then I will attempt to do that, but I was inquiring whether there was something that could be done in the Wimodem232's own firmware to stream outgoing data more smoothly.

Henry
Reply
#9
The WiModem can stream (either direction) continuously forever.  Otherwise uploads and downloads would never work.

Check something for me.  In ProTerm go to terminal mode and type AT&K?  and tell me what the result is.  It has to be 1 for flow control to be enabled.  BBS's are typically very slow, except when uploads/downloads are going on.  So, I guess if the CPU was fast enough and there wasn't much overhead with display handling you might be able to handle normal BBS browsing without seeing dropped characters, especially when a real UART is present (like the SSC).

The WiModem does have a command for changing the internal buffer size before CTS is asserted:

AT*BL[x] – Set buffer limit [limit]

This command will set the buffer limit used before CTS is asserted. Default is 512, with a range of 64 to 1460.
Reply
#10
I thought that you had resolved this issue. After visiting your BBS today I didn't see any type of errors, but I did see at message that there is still an issue. Are you still having this issue? Someone else reported the same thing, and I am 100% sure that this is telnet related since you both are using telnet and they are literally dozens of people running BBS's using WiModem232s that are not using telnet, all without any issues at all.

I need to figure out exactly how to reproduce the problem you are having here so I can actually see it occurring and determine where the problem is. I am guessing it is some sort of odd ball telnet option that I am not supporting - like packet size or flow control.
Reply




Users browsing this thread: 1 Guest(s)