Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.
Please understand that you need to create an account to be able to post, guest posting was disabled as an anti spam measure.
First, I would really take the external tests out of the procedure before there's an explanation for the performance on the LAN.
If it's any comfort, your external results with AmiSpeedTest are much better than mine. 
Number of screen colors, sorry, but this is really far-fetched and unlikely. Please check local network, switch, cables, run a test from Windows to Windows, ask a friend with a Linux laptop to come over, etc. etc.
I took the output of ttcp itself and copy'n'pasted it here.
I took two measurements in each direction, so I edited the output slightly. On the receiving side, I run
$ ttcp -s -r
On the sending side, I run
$ ttcp -s -t ip-addr-or-hostname
For example, just ran it again, I get on the Linux side:
$ ttcp -s -t a500
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp -> a500
ttcp-t: socket
ttcp-t: connect
ttcp-t: 16777216 bytes in 9.69 real seconds = 1690.95 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 4.84, calls/sec = 211.37
ttcp-t: 0.0user 0.0sys 0:09real 0% 0i+0d 792maxrss 0+2pf 573+9csw
Oh, and you know what? ttcp displays Kibibytes, the "old" "Kilobytes", so 1690.95*1024 Bytes per second.
I'm sorry for I didn't notice this earlier.
Sorry, but no, 500KB/sec is not enough in my opinion. Have you tried in both directions?
Amiga 500 OCS Rev.5, ACA1234/50, X-Surf 500 here
Amiga receives with ttcp: 1682.53 1675.75 KB/sec
Amiga sends with ttcp: 692.05 701.66 KB/sec
OS3.1 installation, no fancy things, no MMULib, I was using our network installation with AmiTCP. I have proper network gear and a managed Gigabit switch, but nothing fancy, no speed geekdom, and I tend to run tests in a rather sloppy way. Linux Server is >10 years old and under load, but that should hardly affect the result. So what remains is your switch and other end of ttcp for consideration.
Dear valued customer, would you want to insinuate that we are reading this byte without a good reason?
Would you suggest our software is faulty because of that?
Upon closer inspection you will notice that there is one, exactly one, byte read, not written. And it's always the same memory location.
In general, we do not recommend running ACATool while third-party software is running which might tamper with the CPU and/or MMU. This can give faulty results on certain hardware combinations. For the problems caused by such tools please contact the respective author.
Usually you use programs like that only for debugging your own software during development, and not in daily use.
Why would we react to a such a post? This dump of garbage isn't even displayed correctly, and it was offloaded to the forum without context. User my_pc_is_amiga, what's your problem, exactly?
ACATool 3.5 should fix the flash erase/verify error issue on ACA1221lc with 14MHz.
This is how it's supposed to look like on an A3000 with Kick3.2 and the configuration as shown above (DOM and CF). Maybe you disabled some ports in the Buddha+1 configuration menu?
DEVICE=buddhascsi.device ALSO TRYED DEVICE=budda.device
it only finds compaq flash card nothing else 2nd finds hard drive 3rd finds mod
In case it has escaped anybody's attention:
The device names for the individual ports can be found in the README file.
It's buddha.device, 2nd.buddha.device, 3rd.buddha.device.
You can specifiy the device name with HDToolBox in the command line, for example. We do not provide step-by-step guides for installations with HDToolBox. But you can certainly use HDToolBox with basic Amiga knowledge and documentation.
You certainly better use a version of HDToolBox which is capable of devices bigger then 4GB if you happen to use a device which is bigger than 4GB! Up to and including OS3.1 HDToolBox does not know how to deal with that, so be careful! Also be careful with HDToolBox replacements from Aminet, which might be even worse. We provided our own installer so that Buddha users can set up a system without knowledge about all these peculiarities!
What we did here is that the Buddha+1 controller provides several instances of "buddha.device" for the CF card and IDE ports, so that they can be enabled/disabled and configured individually. We could not continue using the device name "buddhascsi.device" (as in older versions of the Buddha controller), due to name length limitations imposed by AmigaOS. This was a technical necessity, not to annoy anybody.
Regarding bootblock, rootblock, mootpoint... the Buddha controller is completely according to standards, but of course we are using a 64bit-aware device interface, and our installer can provide PFS3, which has no 4GiB partition size or offset limit. If you insist on using tools from the Quarterback Tools era, this might give very misleading and confusing results, and destroy your data. Of course we cannot endorse that.
The list of devices and assignment of ports and device numbering is clearly documented in in the README on the DOM.
With some ASCII diagram and table.
The changes were also in response to customer feedback, including yours.
I don't quite understand what you are talking about here.
"CD drive gets uninstalled after a reboot".
What?
"Do not use the DOM or it will corrupt your WB OS3.2."
This is wrong, or a bug of such grave consequence that it's hard to imagine how it would have escaped our attention in innumerous tests.
The complete procedure of installing OS3.2 from CDROM with or without 3.2 ROMs is described in great detail in the README.
You do NOT have to remove the DOM. And certainly the presence of the DOM should not corrupt anything.
This is purely anecdotal: I had a Yamaha SCSI-to-IDE and a CF adapter in my A3000. Because the SCSI cable is very old and brittle, it repeatedly gave me errors on even minor concussions of the A3000. So I took the CF card into the Buddha+1, disabled the Onboard HD, and never looked back since.
Edit:
Yes, I understand that this wasn't the question. But you should perhaps first try and make sure that the CF works from the CF slot.
But we do have this particular information in our package:
AmiTCP:doc/Interfaces.txt
Add network interfaces in AmiTCP:db/interfaces. Nothing should limit our network setup from using Plipbox or other interfaces. If it doesn't show up automatically in the Advanced Settings, INTERFACE can also be specified in the icon tooltypes.
We have streamlined and stripped down the AmiTCPv4 package to ethernet use, and enhanced it with DHCP support and GUI instead.
SLIP, dialing, and PPP have been removed from the tools and documentation. But it's still the original AmiTCPv4. You could perhaps acquire an AmiTCPv4 license key with our package, and complement it with or use the AmiTCPv4 demo from Aminet, and use it according to the documentation provided with the demo. I'm not sure if this is a sound idea, and we certainly can't provide support for the parts which are not included.
You are not paying for any drivers - they are included for convenience. We're including drivers for the old 10MBit X-Surf card, the new S-Surf-100 and X-Surf-500 cards, and in addition, the archive contains the cnet driver for A1200 PCMCIA networking cards, which is freely available on Aminet.
Minor correction: We are including the drivers for all X-Surf products in our "default" network package. On the ACA1234, the PCMCIA drivers cnet, cnet16 and 3c589 are included for convenience.
have a set of 3.1 ROMs for my A3000D and I will install them and load OS3.2.2 and see how that works.
- You will find OS3.2 not working on OS3.1 ROMs if it was installed on OS3.2 ROMs.
- You will find OS3.2 working on OS3.1 ROMs if it was installed on OS3.1 ROMs (obviously) and you will find it working on OS3.2 ROMs.
Hence the recommendation: Install OS3.2 on OS3.1 ROMs. You can take the installed system to other machines with OS3.1 ROMs.
I don't need 1.3. I may have selected 1.3 from the buddha install in stead of 3.1. I corrected it. The OS3.2 manual states if I have 1.3 on my HD I can install 3.2 on the HD and any incompatible files will be removed and OS3.2 will be installed, which works great. Thats how I been installing my O3.2 and NOT mixing any OS's. The only problem was due to the first buddha IDE as I explained on previous posts.
Why is 3.2 ROMs a bad choice? This right from Hyperion who owns the Commodore / Amiga rights. I have been using OS3.2 and it is very stable. Please explain why it's a bad choice.?
OS 3.2 ROMs are a bad choice with regard to compatibility with other OS versions. That's not to say that OS 3.2 Workbench is a bad choice in general.
We went to great lengths to extend the compatibility of the Buddha product to OS 3.2 - also due to your and other valued customers' feedback. That was challenging when the user has OS 3.2 ROMs installed, because 3.2 has moved several system components from ROM to disk, and this becomes a problem if the user is not installing a 3.2 WB, but some other version.
The Buddha product comes with licenses for WB 1.3, 2.1 and 3.1 - OS 3.2 is a separate product. What's important in this context is that our installer is an option that solves many problems that users often struggle with if they install WB versions up to 3.1 for the first time, especially on big media.
If you are entirely happy with just OS 3.2, you can install 3.2 with the 3.2 installation procedure, and leave the Buddha's installer alone. But then you are on your own with regard to CDROM/DVD support. Of course there is a licensed CDROM filesystem handler and CDROM mountlist examples in Storage/DOSDrivers on the Buddha's install DOM. Installing these, if you are not using our installer, is a manual procedure - albeit harmless, for Amiga experts.
Since the Buddha's installer update to version 1.4, it is possible to install WB 3.1 on OS 3.2 ROMs, and you get CDROM/DVD support provided by our installer. It is then possible for the user to keep the WB 3.1 installation - or to update it to 3.2.
It's about options. My personal recommendation is to keep OS 3.1 ROMs, even if you intend to install 3.2, because this results in a more compatible setup. It results in an installation of WB 3.2 (and 3.1, if you are using our installer) that can work on both OS 3.1 and 3.2 ROMs.
See also the README on the Buddha DOM for some more of the peculiar details.
I just tested booting WB 1.3 on OS 3.2 ROM.
This looks exactly like in your screenshots. Unfortunately, WB 1.3 does NOT work properly on OS 3.2 ROM.
If you need WB 1.3, you must remove the OS3.2 ROM chips and replace them with OS3.1 ROMs.
For compatibility, OS3.2 ROM chips are a very bad choice.
With OS3.1 ROMs everything works - WB 1.3, 2.1, 3.1, 3.2.
This is a very unexpected situation: WB 1.3.3 on OS3.2, and Device pipe: already mounted.
The Pipe handler happens to be used in the Buddha Update/Restore procedure. To me it looks like you might have copied the Update/Restore package - partially or in its entirety - over a former installation, on SYS: level. The Buddha Update/Restore package comes in a directory/folder of its own, and it needs to be invoked from this directory, No manual copying is involved.
I'm not sure if that can fully explain it, but if that was the case, this cannot be corrected. A new OS installation would be required.
Our OS installer shows the right version (1.4), so at some point the Restore/Update procedure went through, or was not needed.
Edit: Or maybe it's much simpler than that, and these screenshots are simply showing a WB 1.3 installation on OS3.2 ROMs. WB 1.3 installations (probably) would not work with OS3.2 ROMs. Sorry for speculations. We just need to understand what was going on here.
