Firebee and NFS ...

All things related to the Atari Coldfire Project

Moderators: Mathias, Mug UK, [ProToS], moondog/.tSCc., Galvez, Moderator Team

User avatar
jfl
Atari Super Hero
Atari Super Hero
Posts: 851
Joined: Tue Jul 18, 2006 10:55 pm
Location: Liège, Belgium
Contact:

Re: Firebee and NFS ...

Postby jfl » Fri Aug 15, 2014 9:07 pm

BlankVector wrote:After running the bad mount_nfs, can you look there:
XaAES menu > Process > System
Then open the Alerts group and tell us what is there.

There are no errors, even with the debug level set to the maximum in xaaes.cnf.
BlankVector wrote:Theoretically, the kernel and its modules use the KERN_DEBUG_LEVEL parameter in MINT.CNF to set the debug verbosity. I suggest you to have a look there.

It's set to the default value of 1. So I don't think these messages are normal.
BlankVector wrote:Also, giving us a sample of those messages would help.

I'm attaching the log file from TosWin's console. This file (1320 lines!) corresponds to entering one folder on the NFS share...
You do not have the required permissions to view the files attached to this post.
Jean-François
GEMDict – GEMClip

User avatar
jfl
Atari Super Hero
Atari Super Hero
Posts: 851
Joined: Tue Jul 18, 2006 10:55 pm
Location: Liège, Belgium
Contact:

Re: Firebee and NFS ...

Postby jfl » Sat Aug 16, 2014 7:56 am

Dal wrote:After reading up on NFS in general it may be there are other forces at play here. From what I've read, when you establish an NFS connection, a reverse DNS lookup is apparently performed - this could account for two problems, namely the overall speed of NFS in general and in Frank's case, the time out error reported by RPC. Easiest way to get around this in a home network environment might be to add an entry for your client (in Frank's case his Firebee) into the hosts file on whatever is acting as your NFS server (in Frank's case, his 'MacPro').

I tried this and it doesn't change a thing. It's still dead slow.
Jean-François
GEMDict – GEMClip

User avatar
frank.lukas
Hardware Guru
Hardware Guru
Posts: 1567
Joined: Tue Jan 29, 2008 5:33 pm
Location: Germany

Re: Firebee and NFS ...

Postby frank.lukas » Sat Aug 16, 2014 11:04 am

I Install EasyMiNT/SpareMiNT on the the Firebee and the Network works fine and the nfs thing works too …

NFS_MOUNT.JPG


I use the 1-18-cur MiNT/XaAES from the Firebee CF Card, with the 1.19 Version from Vincent the Network doesn´t work, I have no Idea what are wrong …

It makes no difference which 1.18 nfs.xfs I use …

NFS are working but it is very, very slowly on the Firebee, on a Atari TT it is all right. The Activity_id Led at the Network Hub flashes very, very slowly …

EASY6.JPG



my mint.cnf ->

Code: Select all

# ---------------- FreeMiNT configuration file ---------------------
#

# The "set" directive controls the behaviour of the mint.cnf parser.
# It accepts one of three parameters:
#
#set -q - silent output (+q for verbose output)
#set -v - print command lines (+v don't)
#set -c - control interpretation of escape sequences

set -q

# The include command allows you to include other files while the
# mint.cnf file is being interpreted. The included file will be
# interpreted as a part of the mint.cnf file.

#include u:/c/mint/vars.cnf

# The smaller the KERN_SLICES value, your processes have faster
# response time but the general performance is worse. Very fast
# machines however, may benefit from setting 1 here.

#KERN_SLICES=2

# KERN_DEBUG_LEVEL controls output of global debugging information.
# The higher the level, the more stuff MiNT will spew about about
# what it's doing.
#
# The average user doesn't want to hear about this stuff, so the
# default is 1, i.e. display ALERT messages only. Note that you need
# a debug kernel to get more: normal kernels do not contain so much
# debug information.
#
# KERN_DEBUG_DEVNO is the BIOS device number to which the info
# should be sent.
#
# Devno can be: 0=printer, 1=aux/modem, 2=screen (console), 3=midi,
# 4=keybrd, 5=raw.
#
# The default is the console.

#KERN_DEBUG_LEVEL=1
#KERN_DEBUG_DEVNO=2

# KERN_BIOSBUF controls how BIOS I/O is performed. Normally, MiNT
# tries to buffer this to provide a (considerable) improvement in
# speed. However, some applications may get upset by this.
#
# KERN_BIOSBUF=NO turns off all buffering for maximum compatibility.
# The default is YES.

#KERN_BIOSBUF=YES

# KERN_SECURITY_LEVEL= enables the appropriate security level:
#
# 0 - recommended for single user setups, like MultiTOS (default).
# 1 - recommended for multiuser setups, like KGMD.
# 2 - full protection, unsupported by software, thus discouraged.

#KERN_SECURITY_LEVEL=1

# KERN_MPFLAGS controls the memory protection behaviour. Its argument
# is a bitfield. Only the bit 0 is defined: 1 means, that more strict
# model of the protection should be enabled. Some programs may
# refuse to run, so the default is 0.

#KERN_MPFLAGS=1

# TPA_FASTLOAD=YES forces fast loading (without zeroing all the
# memory) for all programs. This defines a default state, that can be
# modified later via appropriate kernel calls (use MiNT Setter
# utility to toggle it later when neessary, without reboots).
#
# TPA_FASTLOAD=NO (default) means that the information from the
# program header will be used to decide (this is like TOS does).

TPA_FASTLOAD=YES

# Set maximum additional TPA size for new processes
# (in kilobytes). The default is 1024. Better keep it low (1024 is
# what we call low) if your machine has 4 MB RAM or less.

TPA_INITIALMEM=8192

# FS_NEWFATFS= enables the new FAT filesystem driver for selected FAT
# filesystems. The old TOS FS will be used otherwise.
#
# The default depends on whether the TOSFS driver is compiled into the
# kernel or not. If it is, all drives are TOSFS by default. If not,
# all drives are NEWFATFS by default and this keyword has no effect.

#FS_NEWFATFS=A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,V,W,X,Y,Z
FS_NEWFATFS=A,C,E,F,G

# FS_VFAT= enables VFAT extension for selected drives specified in the
# FS_NEWFATFS= command. The VFAT extension is disabled by default.
#
# If you use both TOS and MiNT, better don't enable VFAT extension
# on your boot drive.

#FS_VFAT=D,E,F,G
FS_VFAT=A,D,E,F,G

# FS_VFAT_LCASE=YES tells the kernel to return lowercase filenames
# from VFAT directory searches. The default is NO.

#FS_VFAT_LCASE=YES

# FS_WB_ENABLE= enables write back cache for selected drives. The
# write back cache is disabled by default. Also, it does not have
# any effect for TOSFS drives.

#FS_WB_ENABLE=A,C,D,E,F,G,H,I,J

# FS_CACHE_SIZE= specifies the size of disk cache in kilobytes for the
# internal caching module. Default is 128.

FS_CACHE_SIZE=1000

# FS_CACHE_PERCENTAGE specifies the size of the disk cache (in
# percents) to be filled with linear reads. The default is 5.

FS_CACHE_PERCENTAGE=10

# FS_UPDATE= set update time for system update daemon in seconds
# default is 5, it isn't recommended to use a value less than 4.

#FS_UPDATE=10

# Software write protection on filesystem level.

#FS_WRITE_PROTECT=R,S

# FDC_HIDE_B= tells the MiNT to remove floppy drive B: from the
# system.
# It is useful on single floppy systems to get rid of "Insert
# disk B: into drive A:" messages from the AES. Default is NO.

FDC_HIDE_B=YES

# PROC_MAXMEM= gives the maximum amount of memory that any process
# may use (in kilobytes). The default is to make this unlimited, but
# if you have a lot of memory and/or programs that grab more memory
# than they should, try setting this.
#
# E.g. to limit processes to 4096K of memory, remove the '#' at the
# beginning of the next line.
#
# WARNING: the process will not be allowed to allocate memory beyond
# the limit, and it won't "see" more memory as available from the
# system.
# Please understand that programs like "free" (or any other that
# interrogates the system how much memory is available) is a process
# as well, thus it will undergo this limit too!
#
# Decent shells (desktops) allow you to limit the maximum amount of
# memory independently for each program.

#PROC_MAXMEM=4096

# Three commands, that define output files for RS-232, console and
# printer devices. The argument for each one must be a pathname.
#
# For best results, the convention u:/drive/pathname should be used
# for all specified pathnames from now on.

#GEMDOS_AUX=u:/c/mint/aux.out
#GEMDOS_CON=u:/c/mint/con.out
#GEMDOS_PRN=u:/c/mint/prn.out

# End of kernel settings

#
# -------------------------- Commands ------------------------------
#

# Here are some commands that you can give to MiNT:
#
# alias d: path -- make a fake "drive" that actually points to the
#                  given path
# cd path       -- changes MiNT's default directory
# echo message  -- print something on the screen
# exec program  -- runs a program; you must give the complete path
#                  and file extensions (e.g. c:/bin/echo.prg)
# include file  -- include another portion of the MINT.CNF file.
# sln path link -- make a symbolic link named "link" pointing to
#                  "path". "link" must be on drive U: for this to work
sln d:\bin   u:\bin
sln d:\lib   u:\lib
sln d:\etc   u:\etc
sln d:\home   u:\home
sln d:\usr   u:\usr
sln d:\tmp   u:\tmp
sln d:\var   u:\var
sln d:\sbin   u:\sbin
sln d:\root   u:\root
sln d:\opt   u:\opt
sln d:\mnt   u:\mnt
sln d:\boot   u:\boot
echo

setenv PCONVERT PATH,HOME,SHELL
setenv UNIXMODE /bsUs
setenv PATH u:\bin,u:\usr\bin,u:\usr\sbin,u:\sbin,u:\boot\mint\bin,c:\mint\1-18-cur\xaaes

# Default login variables. Leave them commented out, if you use
# UNIX style login. If you're using plain MultiTOS and want to
# run UNIX shells under TOSWIN, please uncomment it.
setenv LOGNAME root
setenv USER    root
setenv HOME    /root
setenv SHELL   /bin/bash

# Check filesystems.
exec c:\mint\tools\fscheck\fscheck.prg

# Set up system folders etc
#include u:/c/mint/sys.cnf

# Initalize network.
#include u:/c/mint/network.cnf

# Run Gluestik
exec u:/c/mint/gluestik.prg --force

# Run MGW (Draconis gateway for MiNTnet)
exec u:/c/mint/mgw/mgw.prg

setenv SLBPATH '.\;c:\mint\slb\;c:\gemsys\xtension\;c:\gemsys\slb\'

# The best option is to have INIT= command here, after all pathnames
# are already set up by commands above.

# If the MiNT is supposed to execute GEM, you should specify the full
# path and filename like that:

#GEM=u:/c/mint/xaaes/xaloader.prg

# You can also request MiNT to execute the TOS AES residing in ROM.
# WARNING: this is not recommended, you should use a GEM version
# instead, that is multitasking friendly.

#GEM=ROM

# Otherwise, if your init program is not GEM, you should use INIT= as
# follows:

#INIT=u:/c/mint/1-18-cur/xaaes/xaloader.prg
INIT=u:/sbin/init
#INIT=u:/bin/bash

# If you leave both commands above commented out, the MiNT will
# attempt to execute a file called `sh.tos' found in the system
# directory (the same where the mint.cnf resides), and if this
# fails, the internal minimum shell will be executed.


#
# The "echo" command is really straightforward.
#

echo Setup complete, now booting the system...
echo


Can it maybe that something in the firebee Kernel is not properly or is it the Hardware ...
You do not have the required permissions to view the files attached to this post.
fancy Atari Musik anDA Dance "Agare Hinu Harukana" 1998 ATARI http://www.youtube.com/watch?v=JX10fxb5eYE

User avatar
frank.lukas
Hardware Guru
Hardware Guru
Posts: 1567
Joined: Tue Jan 29, 2008 5:33 pm
Location: Germany

Re: Firebee and NFS ...

Postby frank.lukas » Thu Aug 28, 2014 7:32 am

For testing there are some free NFS Servers for Windows -> http://www.hanewin.net/nfs-e.htm

or -> http://sourceforge.net/projects/freenfs/

or for OSX -> http://www.bresink.com/osx/NFSManager.html

or Classic MacOS -> http://macintoshgarden.org/apps/macnfs-30p3

… as a Network Sniffer use "wireshark" -> https://www.wireshark.org/download.html

Monitoring the TCP / UDP Port 2049 (NFS)

… see the picture - the nfs request is ok, I think. But than the Firebee/Atari is busy (Mouse as a bee) and nothing happens more, the machine run in a loop, I think …

Zwischenablage.jpg
You do not have the required permissions to view the files attached to this post.
fancy Atari Musik anDA Dance "Agare Hinu Harukana" 1998 ATARI http://www.youtube.com/watch?v=JX10fxb5eYE

oehansen
Captain Atari
Captain Atari
Posts: 291
Joined: Tue Apr 17, 2012 12:05 pm

Re: Firebee and NFS ...

Postby oehansen » Thu Aug 28, 2014 6:36 pm

And now I can't get the NFS.XFS to load at all...

User avatar
jfl
Atari Super Hero
Atari Super Hero
Posts: 851
Joined: Tue Jul 18, 2006 10:55 pm
Location: Liège, Belgium
Contact:

Re: Firebee and NFS ...

Postby jfl » Thu Aug 28, 2014 8:25 pm

oehansen wrote:And now I can't get the NFS.XFS to load at all...

How do you know it's not loading?
Jean-François
GEMDict – GEMClip

User avatar
frank.lukas
Hardware Guru
Hardware Guru
Posts: 1567
Joined: Tue Jan 29, 2008 5:33 pm
Location: Germany

Re: Firebee and NFS ...

Postby frank.lukas » Fri Aug 29, 2014 7:42 am

The nfs.xfs is loaded and working ->

ablage2.jpg


Why does have the Firebee/Coldfire Kernel - MiNT Version not the same Features as the MiNT on any other Atari compatible Computer ...?

I don´t get it ...

Whether if something is useful or not, should be left to the user ...


I hope in a new MiNT Version for the Firebee this disgrace will be fixed ...
You do not have the required permissions to view the files attached to this post.
fancy Atari Musik anDA Dance "Agare Hinu Harukana" 1998 ATARI http://www.youtube.com/watch?v=JX10fxb5eYE

BlankVector
Captain Atari
Captain Atari
Posts: 442
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: Firebee and NFS ...

Postby BlankVector » Sun Aug 31, 2014 5:36 pm

After running successfully the FreeMiNT NFS client on ARAnyM, I tried to do the same thing with the FireBee.

mfro wrote:There must be something else going wrong with NFS on the Firebee.

Definitely. It absolutely does not work as expected, with huge timeouts.

First of all: there is an issue with my recent build of ping on the FireBee (both 68000 and ColdFire binaries). It is not able to resolve hostnames (while it works fine on ARAnyM). I tracked the problem down to gethostbyname(). This is currently discussed on the MiNT Mailing List. I suspect a MiNTLib regression.

As a workaround, the old ping binary from EasyMiNT works fine on the FireBee.

BlankVector wrote:You can find a ColdFire mount_nfs there:

That new build of mount_nfs does not work (both 68000 and ColdFire binaries).
It always fails with:

Code: Select all

do_nfs_mount: RPC: Timed out
./mount_nfs-new68k: could not do NFS mount


Again, as a workaround, the old mout_nfs from SpareMiNT works fine.

I suspect it is the same problem as ping, since the symptoms are the same. This will be discussed on the MiNT Mailing List, after the ping issue.

jfl wrote:I finally was able to mount an NFS share on my FireBee with the 68k mount_nfs from SpareMiNT and even if it is dead slow it kind of works.

Same for me. There are huge timeouts, up to 1 minute per operation. During that time, the client process hangs and nothing happens. Sometimes it is a bit faster, some other times operations completely fail after a timeout.

The situation is exactly the same with the ColdFire nfs.xfs or the 68000 one.

There is definitely something severely broken about NFS inside the ColdFire kernel.
On the other side, Samba and OpenSSH work perfectly on the FireBee, so there is no general network problem on the FireBee.
Subscribe to my new channel Vretrocomputing on YouTube and Facebook.

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 745
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Firebee and NFS ...

Postby mfro » Sun Aug 31, 2014 6:14 pm

BlankVector wrote:On the other side, Samba and OpenSSH work perfectly on the FireBee, so there is no general network problem on the FireBee.


Don't know if it might help but it appears there is a pattern:

Samba, OpenSSH: TCP based (connection oriented). Each transfer has a SYN/ACK prolog/epilog.
NFS, ntp, DNS/bind (the ping hostname resolution problem you're facing): UDP based (connectionless). No (protocol based) handshaking.

iperf with UDP does not have problems, however (just tested).

BlankVector
Captain Atari
Captain Atari
Posts: 442
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: Firebee and NFS ...

Postby BlankVector » Sun Aug 31, 2014 6:47 pm

Very good remarks.

This leads us to the following possibilities:

1) Reception of UDP packets is broken.
Could be:
- A bug in select() or something like that. alanh changed things there recently, I don't know if this could be related.
- A bad computation of the UDP checksums on ColdFire, on packet reception. I remember that I it was tricky to convert those assembler routines to ColdFire, maybe there is a bug there. This should be carefully verified.

2) Reception of Ethernet frames are lost.
- Could be a hardware problem (the FireBee Ethernet clocks were bad in the past)
- A problem with the Ethernet interrupt, DMA, etc.
- Some frames could be dismissed by the FEC driver (bad checksum or other reason)
- As you mention, the TCP protocol transparently handles packet loss. So even if several frames are lost, it could be good enough thanks to retransmissions.

We should start to add debug traces in various places, to understand what happens.
Subscribe to my new channel Vretrocomputing on YouTube and Facebook.

User avatar
jfl
Atari Super Hero
Atari Super Hero
Posts: 851
Joined: Tue Jul 18, 2006 10:55 pm
Location: Liège, Belgium
Contact:

Re: Firebee and NFS ...

Postby jfl » Sun Aug 31, 2014 6:58 pm

BlankVector wrote:2) Reception of Ethernet frames are lost.
- Could be a hardware problem (the FireBee Ethernet clocks were bad in the past)
- A problem with the Ethernet interrupt, DMA, etc.
- Some frames could be dismissed by the FEC driver (bad checksum or other reason).

I do see some "dropped frame" messages in the console now and again.
Jean-François
GEMDict – GEMClip

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 745
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Firebee and NFS ...

Postby mfro » Sun Aug 31, 2014 7:02 pm

BlankVector wrote:...
Could be:
- A bug in select() or something like that. alanh changed things there recently, I don't know if this could be related.


Actually, I wouldn't blame a recent change for the problem. I remember I had the exact same problems with NFS when I got my Firebee more than two years ago.

Decided Samba was good enough instead back then and forgot about the issue.

[edit]: it might make sense to first try and set up a scenario that fails on the wire through the loopback interface instead to take the FEC driver out of the equation.

User avatar
frank.lukas
Hardware Guru
Hardware Guru
Posts: 1567
Joined: Tue Jan 29, 2008 5:33 pm
Location: Germany

Re: Firebee and NFS ...

Postby frank.lukas » Mon Sep 01, 2014 10:42 am

I set up a NFS Server on a Ubuntu Box and mount the NFS Share from MacAranym/EasyMiNT and it works …

Code: Select all

c   /   dos   root   wheel   700
d   /   ext2   root   wheel   777

192.168.2.129:/server /nfs/ubuntu nfs rw 0 0


Mount the share from the /etc/fstab …

snap_sh.jpg


.. and it is fast !

I use at home still an old 10 MB/s TP Hub with an BNC uplink for the older Stuff. On a 100MB/s or 1000MB/s network, it is of course still much faster ...

When the NFS Server are running on the same Computer it doesn´t work in my Setup on the Mac ...
You do not have the required permissions to view the files attached to this post.
fancy Atari Musik anDA Dance "Agare Hinu Harukana" 1998 ATARI http://www.youtube.com/watch?v=JX10fxb5eYE

BlankVector
Captain Atari
Captain Atari
Posts: 442
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: Firebee and NFS ...

Postby BlankVector » Tue Sep 02, 2014 9:31 am

Latest news from the MiNT Mailing List:

1) For an unknown reason, the recently compiled network user tools (ping, mount_nfs...) requires a very recent FreeMiNT kernel. Get my latest build for the FireBee there:
http://vincent.riviere.free.fr/soft/m68 ... /freemint/

2) Even with that new kernel, NFS.XFS is still abnormally slow and totally unusable on the FireBee. For an unknown reason, it is significantly faster when there is intense activity on the screen, for example a second TosWin2 window with a program displaying text in a loop. The problem is still under investigation.
Subscribe to my new channel Vretrocomputing on YouTube and Facebook.

User avatar
frank.lukas
Hardware Guru
Hardware Guru
Posts: 1567
Joined: Tue Jan 29, 2008 5:33 pm
Location: Germany

Re: Firebee and NFS ...

Postby frank.lukas » Tue Sep 02, 2014 10:27 am

... many many thanks for the efforts so far ;-)
fancy Atari Musik anDA Dance "Agare Hinu Harukana" 1998 ATARI http://www.youtube.com/watch?v=JX10fxb5eYE

BlankVector
Captain Atari
Captain Atari
Posts: 442
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: Firebee and NFS ...

Postby BlankVector » Thu Sep 04, 2014 5:01 pm

Latest progress:

1) There was a bug in the FEC driver. It caused the NFS server and ping with packet sizes > 1500 to fail on the FireBee. And probably some other network stuff.

2) NFS.XFS (the client) used the TAS instruction, which is buggy on the FireBee. That caused the abnormal slowness and timeouts.

I have provided patches for the above issues to the MiNT Mailing List.
With that, NFS works perfectly and fast on the FireBee :D

I will build a new FreeMiNT kernel archive for the FireBee as soon as the patches are committed.
Subscribe to my new channel Vretrocomputing on YouTube and Facebook.

oehansen
Captain Atari
Captain Atari
Posts: 291
Joined: Tue Apr 17, 2012 12:05 pm

Re: Firebee and NFS ...

Postby oehansen » Thu Sep 04, 2014 6:20 pm

ahhhh .... finally.

Hope it won't be too long ... somebody give them a nudge :-)

User avatar
frank.lukas
Hardware Guru
Hardware Guru
Posts: 1567
Joined: Tue Jan 29, 2008 5:33 pm
Location: Germany

Re: Firebee and NFS ...

Postby frank.lukas » Thu Sep 04, 2014 6:25 pm

I'm glad to hear that, so I´m happy …

I´am looking forward to the new 1-19-cur MiNT package !
fancy Atari Musik anDA Dance "Agare Hinu Harukana" 1998 ATARI http://www.youtube.com/watch?v=JX10fxb5eYE

BlankVector
Captain Atari
Captain Atari
Posts: 442
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: Firebee and NFS ...

Postby BlankVector » Tue Sep 09, 2014 4:47 pm

Finally.

Here is a new FreeMiNT kernel for the FireBee. It includes the fixed FEC.XIF and NFS.XFS:
http://vincent.riviere.free.fr/soft/m68 ... /freemint/

And as a bonus, I have also recompiled the NFS server for ColdFire:
http://vincent.riviere.free.fr/soft/m68 ... fs-server/

Enjoy!
Subscribe to my new channel Vretrocomputing on YouTube and Facebook.

Faucon2001
Atari Super Hero
Atari Super Hero
Posts: 685
Joined: Sat Oct 26, 2013 11:19 pm
Location: Brasil
Contact:

Re: Firebee and NFS ...

Postby Faucon2001 » Wed Sep 10, 2014 12:45 am

Thanks it's working great :D
The NFS share opens and load at a decent speed, around 7 Mb/s !!!

I did some bench on network speed with the Firebee.
My network runs on Gigabit switch and my server spits around 500 mb/s (measured on osx and Linux).
The server is sharing with CIFS/SMB, NFS, FTP
Ftp shell : 6 Mb7s
NFS Firebee : 7 Mb/s
SMBclient Firebee : 11 Mb/s
Ftp Litchi : 14 Mb/s

Litchi win !!! but with a 100Mb interface which can go up to 90 Mb/s on the Firebee, there is still room for improvement. :wink:

Is it a hardware bottle neck or a software one?
Last edited by Faucon2001 on Wed Sep 10, 2014 5:17 am, edited 1 time in total.
Philippe

Firebee, Falcon, STE, Aranym Box, Hatari Pi Box.
My music http://www.philippeworld.net/
My photography http://phil-67.deviantart.com/
EasyAraMint, BeeKey and BeePi https://sites.google.com/site/emaappsarch/home

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 12325
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: Firebee and NFS ...

Postby wongck » Wed Sep 10, 2014 1:03 am

Good to know that a fix for slow NFS is available.
Thanks BlankVector.
My Stuff: FB/Falcon CT63/CTPCI+ATI+RTL8139+USB 512MB 30GB HDD CF HxC_SD/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

BlankVector
Captain Atari
Captain Atari
Posts: 442
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: Firebee and NFS ...

Postby BlankVector » Wed Sep 10, 2014 12:29 pm

Faucon2001 wrote:Thanks it's working great :D

Very good :D

Faucon2001 wrote:The server is sharing with CIFS/SMB, NFS, FTP

If your server has SSH access, you could also test with sftp from the FireBee.

Faucon2001 wrote:but with a 100Mb interface which can go up to 90 Mb/s on the Firebee, there is still room for improvement. :wink:


1) The CompactFlash card is slow (and the SD-Card even slower).
Please download to /ram to avoid mass storage slowness, and test your true network throughput.

2) For maximum performance, be sure to use 100% ColdFire binaries, such as the ones provided on my website:
http://vincent.riviere.free.fr/soft/m68 ... ives/mint/
Subscribe to my new channel Vretrocomputing on YouTube and Facebook.

Faucon2001
Atari Super Hero
Atari Super Hero
Posts: 685
Joined: Sat Oct 26, 2013 11:19 pm
Location: Brasil
Contact:

Re: Firebee and NFS ...

Postby Faucon2001 » Wed Sep 10, 2014 5:54 pm

Yop, I forgot to test ssh : I will look at it tonight.

I don't understand how to download to ram. do you mean to save it to u:/ram?

My setup which is based on easymint has been fully updated with your builds, especially the last mint build, so that's the case.
Philippe

Firebee, Falcon, STE, Aranym Box, Hatari Pi Box.
My music http://www.philippeworld.net/
My photography http://phil-67.deviantart.com/
EasyAraMint, BeeKey and BeePi https://sites.google.com/site/emaappsarch/home

BlankVector
Captain Atari
Captain Atari
Posts: 442
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: Firebee and NFS ...

Postby BlankVector » Wed Sep 10, 2014 6:00 pm

Faucon2001 wrote:do you mean to save it to u:/ram?

Yes. u:\ram (or /ram in POSIX notation) is FreeMiNT's ramdisk.
Subscribe to my new channel Vretrocomputing on YouTube and Facebook.

Faucon2001
Atari Super Hero
Atari Super Hero
Posts: 685
Joined: Sat Oct 26, 2013 11:19 pm
Location: Brasil
Contact:

Re: Firebee and NFS ...

Postby Faucon2001 » Sat Sep 13, 2014 6:08 pm

This is the results of different Firebee network tools.
This time I did it more precisely by measuring 5 times the downloading time for the same file (15 MBytes zip archive) on my server and using the same disk on the Firebee. I also did the test as suggested downloading to file /root and to ram /ram.
My setup is based on EasyMint updated with the lastest builds from Vincent of Mint 1.19.CUR and Mint tools.

Image

First observation : NFS can achieves up to 10 Mbits/s !!!
Depending on the tools, downloading to /ram may improve dramatical the speed (FTP shell) or not (NFS Desk)
SMB client is 20% faster than NFS. I have not been able to use sharity light so far.
Something is wrong with SSH (latest build from Vincent) as it is SLOOOOOOW
Litchi remains the most effective one.
Same file on OSX or Xubuntu download @ 450 Mb/s.

In conclusion, NFS is fast enough to be used with small files, which represent 90% of Atari files :-)
For the biggest ones, I use litchi which on top of it works perfectly with drag and drop on the desk, so almost as a remote drive.

My first question on Firebee network speed remains. With a 100 Mb/s interface we could expect 90 Mb/s effective speed. Is it MintNet which is slowing down transfer or is it hardware related?
Philippe

Firebee, Falcon, STE, Aranym Box, Hatari Pi Box.
My music http://www.philippeworld.net/
My photography http://phil-67.deviantart.com/
EasyAraMint, BeeKey and BeePi https://sites.google.com/site/emaappsarch/home


Social Media

     

Return to “FireBee”

Who is online

Users browsing this forum: No registered users and 1 guest