THE WAKE UP CHANNEL
Go to bottomPage: 12345
TOPIC:
*
#595
Re:Any way to get sources for ZTP 1.34? 6 Years, 2 Months ago Karma: 1
Today, while testing a new thing for HACK-RTOS - the remote update capability, I have run into some troubles with my TCP stack. Apparently, the new thing uses it in a way different than that of my old TCP test client. There is still work for me to do.

You know, John, maybe you should remind Zilog of your original request. They might believe I have successfully put it out of your mind with my HACK-RTOS.
Alex K (User)
Junior Boarder
Posts: 23
graphgraph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
#589
Re:Any way to get sources for ZTP 1.34? 6 Years, 2 Months ago Karma: 0
See if you can find yourself a used Cisco rack-mount router with their store and forward, that might be a better test, and then than feeding a hubbed net - we catch more problems that way. You want the subjects under test to see lots of traffic, in lots of combinations, with lots of different setups. You'll also find out that different MAC / PHY chips behave differently with different Ciscos...and I'll leave that for you to discover;)

Also find out the differences between the Acclaim! MCU and the Acclaim!Plus. They aren't the same, and they are not drop-in replacements for each other. You'll find that out also.

Yes, we use a remote update system over Ethernet, but because the equipment has to stay operating, it will fail over to the backup controller during a firmware upgrade - nothing is ever, ever powered down or reset. The system is vulnerable though because it absolutely can't get hung during the firmware upgrade - that might require a physical presence.

We really, really try to not release anything until its tested and working -we send a minimal amount of software upgrades out (one per year at most unless there is a major problem). We don't believe in making the end customers be beta testers, as much as we can.
John Anderson (User)
Senior Boarder
Posts: 42
graphgraph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
#588
Re:Any way to get sources for ZTP 1.34? 6 Years, 2 Months ago Karma: 1
I have done what I wanted today. I have made a router out of my PC, and have got two subnets, plugged eZ80 in one of them, started several TCP clients in both subnets plus a few pings, and guess what? It just started to work! Truthfully, I expected troubles because I never much tested that "default router" thing in the stack, but no. After 5 hours of testing no problems whatsoever.

John, if I may ask, when you need to update the firmware of the unit in the field what do you do? Does RZK 1.34 provide means to do it remotely over Ethernet, or do you need to climb towers and ride helicopters?
Alex K (User)
Junior Boarder
Posts: 23
graphgraph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
#587
Re:Any way to get sources for ZTP 1.34? 6 Years, 2 Months ago Karma: 1
Well, I suppose if someone decides to send me a TCP segment bigger than 1500 bytes, it would result in several fragmented IP datagrams. Fragmented datagrams are discarded by the stack. They don't frighten me at all.

Concerning the counters, all counters that HACK-RTOS uses are signed 8-bit ones. That is, I only have to test for 255 system ticks or seconds depending on the counter type. Lucky me!

What I want to test now is a communication over a router, where eZ80 is in one subnet and the client is in another. The immediate problem I'm facing is that I don't have a router. Will have to find a way to make a PC to do the job.
Alex K (User)
Junior Boarder
Posts: 23
graphgraph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
#586
Re:Any way to get sources for ZTP 1.34? 6 Years, 2 Months ago Karma: 0
That's MTU, not MSS, Alex. Over RF-based Ethernet links you'll have MTU's of almost any size. 10 or 64 or 100 bytes can happen also on a noisy RF link. On the GigE or fiber net's you'll run into jumbo packets (usually around 9k) or up to 64k (Super jumbo packets). Sometimes we have the usual 1500 or 1522 bytes (VLan) but the stack has to play nice no matter what MTU is in use - or trying to be used. Its not that the Zilog has to handle a 64k packet for comms, but it has to not get stuck if the equipment its connected to is trying to do that for some reason. We've seen that happen.

There really isn't any PC-based "load-stress tester" app that we've found that can simulate a real-world wild network. Those programs are a start (and help when you're trying to zero in one one specific problem) but they aren't an absolute substitute for reality.

Why do we test for at least 3~4 weeks?: Because beside solid operation on the 'Net we're also looking for any seconds rollover problem in the time keeping mechanisms. We've seen problems with stack - and our own software - and with GPS receivers - that fail after 24.85 days of uptime. That's because a 32 bit signed long counter, updated every 1mSec (very, very common), will fail exactly at that time if it doesn't handle the rollover correctly. An unsigned long counter will fail after 49.7 days if the system isn't designed for that. Even Trimble has this problem on some of their newer GPS receivers, which they weren't even aware of until we started doing extended testing last year - on the 25th day, the GPS receivers on all of our units would develop all sorts of random features just like they had a bad memory pointer. And that's exactly what the problem was.

So, Alex, you can't really test a stack for reliable operation in 8 hrs. It takes much, much longer than that to really look for those "gotcha" problems. You can look at the code and swear nothing could possibly break it, and then you put in on a wild network and be humbled every time.
John Anderson (User)
Senior Boarder
Posts: 42
graphgraph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
#585
Re:Any way to get sources for ZTP 1.34? 6 Years, 2 Months ago Karma: 1
Thanks for the suggestions, John. I'm not sure about 50 - 220 units on a hubbed network. I'm testing my one unit on an isolated network consisting of around 10 hosts.

Though I haven't been able to send IPv6 pings to the MCU (it appears that NDP protocol encapsulates its messages in something other than RFC-894 Ethernet), I'm pretty sure they can do no damage to the stack. The first check there is to compare the Type field of the Ethernet header with 0800 (IP datagram) or 0806 (ARP request). If it is something different, the frame gets deleted.

About VLAN packets, I just don't know where can I get some, but again, I can see the place where they are supposed to be filtered away. No way they could pass that place, unless the Zilog documentation is misleading on the subject.

When you speak of MTU of 10 bytes, I presume you really mean MSS of 10 bytes (TCP Maximum Segment Size). That's that is involved in negotiations when a TCP connection is established. Different MSS have never been a problem. I usually use small ones like 191 bytes. That way it is possible to make about 10 TCP clients to send & recv data to the MCU continuously and simultaneously without hindering each over. I was unable to achieve something comparative from ZTP. With ZTP, when I were to add third TCP client (my TCP_Client.exe), transmissions were becoming jerky because of packet losses and subsequent retransmissions.
I'm not sure about 9k/15k MSS. I thought that MTU of Ethernet is 1500 bytes, and MSS may not exceed it.

Your testing environment looks very tempting to me. It's a pity I don't have access to something like that.
Alex K (User)
Junior Boarder
Posts: 23
graphgraph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
Go to topPage: 12345
The Sample Center is managed separately
from Zilog's Customer Support services,
and therefore requires a separate login.
Acknowledged! Take me to the Sample Center.
Disable this pop-up in the future.