I just uploaded about 4GB of new mp3's via USB (win2k Dell GX300 933Mhz 256MB 10k 18Gb HD) and it took nearly 3 and a half hours!!!

Is this typical?

332 Kbytes/sec?

In a word, yes it's typical. Indeed, it's pretty good.

Peter

Yeah, as Peter said, that's pretty decent for USB. That's 3 megaBITS per second, or 384,000 BYTES per second, depending on how you do the math. Admittedly, the theoretical maximum speed of USB is closer to 10mbps. But protocol overhead robs some of that, plus you're discovering one of the truisms of manufacturer's bandwidth claims: You usually only get about half of their theoretical maximum. (Note that I'm referring to the USB hardware manufacturer in this case, not Empeg- no matter how efficient the Empeg is at using the USB port, there's still inherent hardware and driver limitations that they can do nothing about.)

Remember that you won't be doing that very often: Sending 4GB at once. Usually it'll only be a couple of albums at a time, and that will only take a few minutes.

___________
Tony Fabris

Greetings!

Is ethernet significantly better in this kind of situation (i.e., large amounts of data)? I will be loading over 18GB of data to start with (from the sound of it, over multiple sessions...). Just trying to plan strategy now...

Paul G.
Q# 15189
Status: In queue for a green 36GB Mk2

Yes, rumor has it that ethernet is slightly faster than USB at the current time. I don't know which is more reliable. I've heard of people who got synch errors via ethernet as well as USB.

___________
Tony Fabris

Yes, rumor has it that ethernet is slightly faster than USB at the current time. I don't know which is more reliable. I've heard of people who got synch errors via ethernet as well as USB.

Ethernet is nominally slightly faster than USB, although in practice I only get about 300Kbytes/sec over Ethernet this is slower than jwtadmin gets over USB but then I don't have such an "ass of iron" PC...

Personally I think Ethernet's more reliable than USB, although that's probably because I'm a bit of a luddite at heart and don't trust this fancy new USB stuff . If TCP/IP were broken, people would have noticed by now...

Peter

After installing an FTP server on the Empeg, I swear the transfer rates are faster than via emplode. How could this be possible?

Overhead.. Right now, Emplode's using the error-correcting protocol that they've designed mainly for USB - which tops out around 350k/sec... FTP uses the TCP/IP stack, which tops out around 1mb/sec.. Empeg has stated that they will eventually (possibly?) use the TCP/IP stack when possible with ethernet to achive higher speeds...
-mark

MK2: 36gb
Tivo: 90gb
CPU: 120gb
...I think drive manufacturers love me!

I have been uploading 16+gig over and over again ( dont ask why ), and via ethernet I just set it going, go to bed, and its normally just about done when I wake up.

- --
Rod, UK Mk2 18gig Red S/No.341

Yes, rumor has it that ethernet is slightly faster than USB at the current time. I don't know which is more reliable. I've heard of people who got synch errors via ethernet as well as USB.

ACK, I got synch errors on ethernet as well as on USB.

Ethernet is nominally slightly faster than USB, although in practice I only get about 300Kbytes/sec over Ethernet this is slower than jwtadmin gets over USB but then I don't have such an "ass of iron" PC...

Hmm, USB should be harder for the CPU than TCP/IP, as far as I know, but that probably depends on quite some things, like controller used on the NIC, USB chipset, drivers etc.

Personally I think Ethernet's more reliable than USB, although that's probably because I'm a bit of a luddite at heart and don't trust this fancy new USB stuff . If TCP/IP were broken, people would have noticed by now...

Well, I got around 250kB/s over USB, and well over 500kB/s over Ethernet. And Ethernet really seems to be far more stable than USB, at least on both my laptop (PIII/650, 128MB RAM) and my desktop (K7/500, 256MB RAM). BTW: TCP/IP has quite a few quirks, but mainly security problems.

cu,
sven

Well, I got around 250kB/s over USB, and well over 500kB/s over Ethernet.

In general use, or using emplode/emptool? If you mean generally, then 250K/s sounds a bit slow for USB; if you mean using emplode/emptool, then 500K/s sounds unusually fast for Ethernet...

Peter

Well, I got around 250kB/s over USB, and well over 500kB/s over Ethernet.

In general use, or using emplode/emptool? If you mean generally, then 250K/s sounds a bit slow for USB; if you mean using emplode/emptool, then 500K/s sounds unusually fast for Ethernet...

I was talking about emplode (don´t has any experience with emptool). And I wondered why the rate was that high myself. Maybe my switch is involved in getting it a bit faster (full duplex as opposed to half duplex)? Maybe my pretty fast ethernet card (don´t know the exact brand, but using a 100Mbit connection to my linux server, I get up to 8MByte/s via ftp) is a factor, maybe both. I simply don´t know why, but the rate is that high.
Nevvertheless, restoring all my music (5GB MP3 currently, quickly growing) to the empeg would still be an upload of 5,000,000Byte/(500,000Byte/sec)=10,000sec or approximately 2hours 50minutes (3600 Seconds/hour).
Enough time to drive donwtown, go to a good restaurant, have a long and good meal, goto to a cocktail bar, have a drink or two and go back home using a cab/taxi ;-)

cu,
sven

Well, I'm on day 2 with my empeg.

On day one, I hooked mine up via ethernet (because I don't have a USB capable machine, I'm on NT4). I got the Ethernet working no problem, first by setting up a DHCP server on my linux box....then I changed the empeg's settings to static address and turned the DHCP server back off. Works totally great. It was very easy. I think the people having problems with ethernet are possibly not as savvy about network config issues. USB is much easier I would guess...just plug and play.

Round 1

At any rate, i tried my first sync with a small batch of 30 songs. Maybe 200 MB total. It took 3-4 hours. Talk about slow! However that was actually going through a narly network path:

linux samba shared volume ->through hub->through wireless ethernet card on NT box->mounted on NT->copied through emplode->pushed out wireless ethernet card->through net hub->out to Empeg unit.

And all the while that transfer was going on, I was doing some other heavy downloading on another machine, but through the same net hub...

Round 2

Ok, so round two I decided not to copy off linux net volumes. this time I put a CDR disc into my NT machine and tried to copy straight from there..using emplode. I did a little bit of surfing on another machine during this too, but not too much... this time it took 2 hours..but to copy an entire CDR...650MB. Still pretty damn slow. But getting better.

Round 3

I installed 1.01 OS on empeg...and installed 1.01 emplode. I got rid of the wireless ethernet adapter and plugged a regular 10mbps card into my NT laptop. I also got a cross connect ethernet cable and plugged the NT machine directly into the Empeg. Guess what...did a whole CDR in like 10 minutes. 650MB. I'm not kidding. It was REALLY fast. I couldn't be sure...but I was counting off maybe 7-10 seconds per song(and my songs tend to be 5-7MB each in 190kbVBR).

So...I was definitely getting something between 500kbps-1000kbps....which is plenty fast as far as I'm concerned. I want to try the wireless card again with cross connect cable to see if the hub is causing the bottleneck. Its probably a little bit of everything. Anyway, its going super fast now!

cheers
-steve
sjs@bstage.com

I want to try the wireless card again with cross connect cable to see if the hub is causing the bottleneck.

Well worth trying... these wireless cards often fall back to 2 or even 1Mbit/sec if they can't connect at the ideal 11Mbits/sec.

500Kbytes/sec is a very good result over Ethernet with the currently-released software. The raw bandwidth we get off our dual-P3 server over switched Ethernet into the player and into a disc file is only about 850Kbytes/sec, and there's a fair amount of overhead in the current protocol.

Peter

Just thinking out loud but ...

This is all half-duplex (or so it seems) ... Would it be possible to design a push & pull client-server combo for the empeg and its complementary emplode/emptool software that divvies the workload in 2 roughly then pushes half 1 from the desktop to the empeg while the empeg itself pulls half 2 from the from the desktop ? This of course is only possible if the network connection on both (and your intermediate infrastructure i.e. hub/switch/...) the empeg and desktop supports it. I was surprised though that it was 'only' a 10 Mbit network card. Was there some binding factor for that choice ?

Cheers,
Hans


Mk2 - Blue - 080000431

Why do not use a dual channel solution then: use ethernet and USB at the same time

Frank van Gestel

Errrrrr, that's not how networks work. You can't push from one end, pull from the other, and expect it to be any faster. There is a maximum amount of bandwidth in each direction, and you can't "contribute" upstream bandwidth to give more downstream!

Splitting it over ethernet/usb would be a nightmare, and wouldn't result in 2x performance - USB heavily loads the empeg with interrupts and would slow down ethernet transfers.

It's 10Mbit as 100 is really not necessary; the empeg is not a fileserver. Also, 100mbit chips are much more expensive (we're talking about ones that will interface to an ISA-style bus, ie they have at least 64k of packet buffer, etc - PCI ones are cheap, but there's no PCI in the empeg. For ISA-style ones there are only a couple to choose from), physically larger (no integrated PHY, etc), and cause lots of EMC headaches.

Hugo

Hey sue me, I am really overstressed at work and this should show how much really ... I realised the error of my ways the second I hit the submit button .

Cheers,
Hans

Mk2 - Blue - 080000431

It would be cool if that's the way they worked...

Calvin

Well, I was definitely WELL above 500kbps.... I did 650MB CDR in about 10-12 minutes.... that's about 1 MB per second. Mighta been slightly less, but I'm guessing it was close to the 850 figure you mentioned above....and this was using emplode by the way. However, my Empeg is still relatively empty. Maybe as it fills up it will slow down a little?

However, my Empeg is still relatively empty. Maybe as it fills up it will slow down a little?

Shouldn't do. But it is possible that your empeg with a nice big modern disk has much better disk bandwidth than mine with a slightly clunky Toshiba 14G unit of a type which I don't think we ever shipped to users.

(Even a crap disk's bandwidth is much more than 850K/sec, of course, but the point is that the CPU is quite busy when it's talking to the disk, and the less time it spends busy, the more time it has to service network traffic.)

Peter

In noticed something similar. As the player program is refilling it's cache from disk, network-traffic seems to stop completely for some seconds, though this is probably due to the realtime-environment in which the player is running

Frank van Gestel

As the player program is refilling it's cache from disk, network-traffic seems to stop completely for some seconds, though this is probably due to the realtime-environment in which the player is running.

Yes. If you're talking about protocol traffic to emplode/emptool, then the player thread which services this traffic runs at lower priority than the other player threads. If you're talking about another process running alongside the player, then unless it's SCHED_RR it'll be running at much lower priority than the player -- indeed, if any SCHED_RR thread or process is runnable, no other process will run.

Peter

As I remember, processes which are waiting for resources get moved from runqueue to sleepqueue. Other processes waiting for resources would allways end up in the sleepqueue below the realtime process. As the CPU can handle more IO than any physical device can deliver, this would be the cause of the network-lag in normal processes.
Am I correct ?



Frank van Gestel