CIFS speed fomula

How much of that 1Mbps is being used?  If you have 1MBps line but it's being shared you're not really getting 1MBps.  When you open a file it caches a copy on your computer and then opens from there.

1Mbps connection is 1000 bytes / 8 bytes = 125 KB/s transfer rate.  So if you are opening a 1.25MB file it will more than 10 seconds to download and then open locally.  This implies that you have the full 1Mbps allocated for this one person and for this protocol.  Typically the connection is being shared so your throughput is degraded for this session and you have to take that into account as well as overhead for any VPN and/or remote connections

As @paulsolov is pointing out, your remote connection is much slower than your local hard disk.  Local hard disk transfer speed these days with SATA drives is more than 1Gbps or 1000 times faster than your remote connection.

Latency has a huge impact on CIFS/SMB1 traffic. Latency is how long it takes a packet to get from one computer to another. CIFS requires many round trips to complete a transaction, which is why it will feel slow over high latency WAN links, even if there is plenty of bandwidth. SMB 2.0 and later (Windows Vista/Windows 2008) have been redesigned to work well over WAN links.

I haven't tested CIFS speeds in Vista or 2008, but for some reason, all earlier CIFS implementations have only ever utilized about 1/4 to 1/3 of the ethernet pipe, even on LANs, to transfer files.  Years ago, I used to install Helios PCshare or Xinet software on servers to utilize the maximum throughput for many graphics shops that really needed the full gig network speed for their large file transfers.

Helios is still selling PCshare.
http://www.helios.de/viewart.html?id=729-en

I don't remember the original Xinet product name, but it was a full feature asset management suite that included a faster built-in CIFS share.  I don't know if their new WebNative product does that.
http://www.xinet.com/index.php

If you want faster CIFS file transfers, those were the two companies I dealt with long ago to handle that.  From what I remember, these are pretty much drop in CIFS replacements, but they did cost a few thousand dollars.

The Helios site used to have a file transfer speed test utility, but I don't see it there now, or I'd run a test again on a 2008 system to see how fast the speeds are these days.  It's been a long while since I checked their site.  I remember testing XP on a gig link and CIFS was just slow back then.

I heard CIFS limits window size up to 3K byte.
This means , in case of 3Mbyte file transfer via CIFS, 1000times packet need to go back and forth.
and, in case of Network latency 200msec, transferring takes at least 200seconds. is this correct ?
(On the premise of all network bandwidth available)

If yes, in this case, how can I consider network bandwidth ?
in case of 2Mbps Network bandwith , how this affect 200seconds ?

> 1Mbps connection is 1000 bytes / 8 bytes = 125 KB/s transfer rate

That's partially correct.

1Mbps is 1,000,000 bits per second, divided by 8 (bits per byte) for 125,000 bytes per second.

Technically the answer (125KB/s) was correct, but the process to get there was not.

Also, frame, ACK and protocol overhead was not taken into account, and depending on if VLANs, IPv6 and TCP timestamps are used, that overhead could range from 5.1% to 7.4%, ergo maximum possible throughput would range from 118.8KB/s down to 115.75KB/s.

So, if you have sole use of your 1Mbps connection, and error-free transfers, minimum load times should be about 8.5 seconds per MB (that's 1,000,000 bytes; not MiB which would be 1,048,576 bytes).

To address the title question, apparently there is a constraint on the way the linux CIFS client accesses files that limits it to around 30MB/s, but that's nearly 250 times your internet connection's speed, so it should be quite some time before you might run into problems from that source.

I concur, the 125kb/s was used as an example for providing theoratical capacity, overhead will always cut some of it out.

I don't see latency included in any of the calculations, and the impact of latency can be significant, both in terms of real world useability, and actual throughput. What we don't know is if this is a theoretical question, or a real world problem. What operating systems are involved? Windows Vista or better connecting to Windows 2008 or better will be much more useable than Windows XP due to SMB protocol differences.

If we want to go fast let's just install NETBUI..just kidding ofcourse

I think we need to outline what is the user currently experiencing, what is the lag, and what is the current bandwith from source to destination. That will provide us with a bit more to work with.