Jump to content

Manni01

Members
  • Posts

    17
  • Joined

  • Last visited

Manni01's Achievements

ISF Newbie

ISF Newbie (1/5)

  1. No problem, I understand. Just trying to provide as much info I can. If you let me know what the options are in the new build, I'll be happy to test for you. Appreciate your excellent support as always
  2. A couple more things: 1) I was wrong, the buffer is empty during the NAS>NAS operation, so it's read limited. 2) If I start two instances of IMGBURN copying different files from the same NAS1 to the same NAS2, I get around 22MB/s for each instance, which totals to more than the 30MB/s I get when only one instance is running. This shows that we should be able to reach at least 45MB/s during one operation if it was optimised.
  3. I've done the test, and here are the results with IMGBURN: HDD -> NAS1 = 90MB/s NAS2 -> HDD= 70MB/s When at the same time, NAS1 holds its speed and NAS2 drops to 20MB/s, which is consistent with max speed of 110MB/s on the gigabit network. NAS1 -> HDD = 70MB/s HDD -> NAS2 = 95MB/s When at the same time, NAS2 holds its speed and NAS1 drops to 15MB/s, which is also consistent with max speed of 110MB/s on the gigabit network. So I would expect an optimal NAS1 to NAS2 to be around 50-55MB/s, at least 50% faster than what it is at the moment (around 30-35MB/s).
  4. I was preparing to do the requested test, but I discovered something which might help us understand what's happening. I didn't have any bluray folder on my local drive, so I mounted an ISO from one of the NAS using Virtual Clone Drive, and started copying the content to my local drive (an SSD delivering 200MB/s + speed with large files in R/W to rule out any HDD induced bottleneck in the experiment). This is on a quadcore with gigabit ethernet. I was surprised to see that the speed, even when copying the main .m2ts (so a large file) was only 32MB/s (roughly the performance of IMGBURN when reading from a NAS and writing to another). Once the copy was over, I tried to copy the ISO itself from the same NAS to the same local drive, and I got my usual 100-110MB/s. So I had a look at the settings in VCD, and buffered I/O was enabled. I disabled it, tried to copy the BDMV from the mounted ISO, and the speed shot up to 50-60 MB/s (about double). So it looks like 1) buffered I/O seems to have a negative influence on the copy speed, at least for VCD and 2) VCD seems to suffer from the same drop in performance as IMGBURN when reading from a NAS compared to direct file copy. If I write to the NAS, I get the expected performance (around 100MB/s with direct filecopy, and around 95MB/s both with VCD and IMGBURN (so an acceptable overhead), whether buffered I/O is enabled in VCD or not. So limitation seems to be when reading from a network share with some tools, but not when copying files directly. Does that help? If buffered I/O is disabled for reading in IMGBURN, it shouldn't impact performance negatively if it behaves like VCD, as worse performance comes when it's enabled.
  5. Any way to enable buffered I/O for the writing? That might improve things. Could there be some collisions due to the sustained high bandwidth reading/writing going through the ethernet connection simultaneously in opposite directions? Or maybe a timing issue? Only trying to understand why the performance is so much lower than it should, I realise that IMGBURN doesn't handle directly the low level traffic between source and dest.
  6. Buffer looks normal (full), except at the very beginning when it fills up progressively, and at the very end when it empties progressively. It looks to me like it's related to the way IMGBURN handles the I/O when both source and dest are a network share. Again, when the share is only a source or destination, it goes at full expected speed, which proves that it's not related to either the source or destination per se. If I reverse source and dest, I get the same (low) performance, around 30MB/s.
  7. Thanks for your quick reply, and apologies for my late reaction... I forgot to click "follow this topic"... I tried to enable OS buffering and it doesn't improve anything. As I said, I am reading from one NAS and writing to another, so it's a different physical device. Each NAS is able to do around 100MB/s read/write, so saturates the gigabit / CAT6 connection. Except when IMGBURN is doing the reading/writing to/from two separate NAS. It goes like this: LOCAL DRIVE --> IMGBURN --> NAS1 or NAS2 = 100MB/s NAS1 or NAS2 --> IMGBURN --> LOCAL DRIVE = 100MB/s NAS1 --> IMGBURN --> NAS2 =30 MB/s I tried selecting Elby I/O instead of MS, and it doesn't make any difference either. Any other idea? Have you done first hand tests using network shares (NAS, not MS client) as source/dest?
  8. Hi there, I'm wondering if there could be a way to optimize imgburn's performance when reading AND writing from/to the network. If I only read from a NAS share to a local disc, or write from a local disc to a NAS share, performance is as expected (around 100MB/s on my gigabit CAT6 network). But if I read froma NAS share and write to another, the performance drops to around 30MB/s. Given the limitation of the network, I would expect it to drop around 45/50MB/s, possibly a bit less. I use a QNAP TS859, a Qnap TS809, and a Synology DS2411. Clients are Win7 x64 ultimate destops or laptops. Any idea why the performance is not so good over the network? I tried with different clients, and different NAS, imgburn seems to hit a ceiling around 30-35MB/s in this situation. Thanks!
  9. Tried it and it worked perfectly, thanks again Google let it through, thanks to your clever renaming
  10. Thanks. I tried disabling this option (which was checked, you were right), but it now comes up with a non-related two letter volume name, not the source folder name as it used to before the update. I have no idea what has changed in the new code, but I know that it worked fine before, and used the source folder name as defaut for both the file name and the volume label If there is no way to revert to the last version, I guess I'll just have to copy and paste the file name... not a great solution.
  11. Understood, but unfortunately the new code (I mean, before the changes you mentin which I I haven't seen yet!) doesn't work. All the label names it comes up with are fancy nmes with spaces, special chracters, etc. Volume names are usually something like BAD_TEACHER, not Bad Teacher 2011 © Any chance to get a simple option like volume name = file name? You get the file name right (it's the same as the source folder by default), so why not having the option of using the same for label as before? Otherwise is there a way to download the version before the last one (I foolishly haven't kept it)? This is a problem with every burn, while the missing BDMV folder is an issue only once in a while, so I'd rather deal with that... Thanks!
  12. Thanks for implementing this in 2.5.6.0. It seems to work fine. However, it looks like you have changed something in the default label name. Before, it would use the source folder name (the folder containing the BDMV and CERTIFICATE folders) for both the ISO default name and the label name, now it seems to be using the source folder name only for the ISO default name, and the destination folder name for the label. Any way to revert to the old naming behaviour? Thanks!
  13. Hi there, Any update... on the availability of the update?
  14. This is great, thanks! Any idea when the update will be available for download?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.