cloud server(Fairlight)
Fairlight
fairlite at fairlite.com
Tue Mar 22 11:36:52 PDT 2016
Actually, I was only partly right, and you were partly right as well.
Just spoke with a full-on network engineer about the topic.
The difference is that MTU affects layer 2, while the tuning for NFS, CIFS,
SMB, etc., is layer 3, which sits on top of layer 2.
Yes, I'm correct in that your 8KB or 64KB packets would get sliced into
1500 byte packets via MTU at the layer 2 level.
However, there is TCP window size, as you suggested. That takes place at
layer 3. The main advantage of this is in determining how much data can be
sent before an ACK is required in TCP. It both saves ACK space on
asymmetrical conversations, and will spead things up. It's a more subtle
difference than turning NFS sync on/off, but in the same vein.
Apparently dynamic window sizing does exist, and has been around in Linux
for a while.
So we were both partly right and partly wrong.
mark->
On Sat, Mar 19, 2016 at 01:19:33AM +0000, Jason Garner via Filepro-list thus spoke:
> No I am sorry you are right. I got my wires crossed.
>
> I was thinking about smb buffer default size of 64k in windows waiting for
> an ack and confused that with packet transfers.
>
> On Fri, Mar 18, 2016 at 7:48 PM <filepro-list-request at lists.celestial.com>
> wrote:
>
> > Send Filepro-list mailing list submissions to
> > filepro-list at lists.celestial.com
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > or, via email, send a message with subject or body 'help' to
> > filepro-list-request at lists.celestial.com
> >
> > You can reach the person managing the list at
> > filepro-list-owner at lists.celestial.com
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Filepro-list digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: in Linux using "screen" command produces "segmentation
> > violation" when trying to run filepro. (Bill Campbell)
> > 2. batch file of dreport commands and global variables
> > (Jerry Crespi)
> > 3. Re: Re cloud server(Fairlight) (Fairlight)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 18 Mar 2016 16:34:43 -0700
> > From: Bill Campbell <bill at celestial.com>
> > To: filepro-list at lists.celestial.com
> > Subject: Re: in Linux using "screen" command produces "segmentation
> > violation" when trying to run filepro.
> > Message-ID: <20160318233443.GA3251 at ayn.mi.celestial.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Fri, Mar 18, 2016, tony via Filepro-list wrote:
> > > hi experts
> > > i am trying to use "screen" command in linux. works great except for
> > > filepro which gives a segmentation violation.
> > > env returns a TERMCAP listing and no variable for TERM.
> > > i tried TERM linux; export TERM, but the segmentation violation
> > continues.
> > >
> > > any suggestions on how to fix it.
> >
> > I've put a wrapper around the FilePro 'p' command that
> > manipulates the TERM environment variable. Something like this:
> >
> > #!/bin/bash
> > PFPROG=/home/appl
> > PFDATA=/home
> > PFDIR=/appl
> > PFDSK=/home/appl
> > PFMENU=/home/appl/fp/menus
> > PFGLOB=/home/appl/fp/lib/edits
> > PFCONFIG="/home/appl/fp/lib/config"
> > TERMCAP="/home/appl/fp/termcap"
> > TERMCAP="/csoft/etc/fptermcap"
> > case "$TERM" in
> > xterm|xterm-color) TERM=xterm-linux; export TERM;;
> > SCO) TERM=scoansi; export TERM;;
> > esac
> > export PFPROG PFDATA PFDIR PFDSK PFMENU PFGLOB PFCONFIG TERMCAP
> > /home/appl/fp/p "$@"
> >
> > Bill
> > --
> > INTERNET: bill at celestial.com Bill Campbell; Celestial Software LLC
> > URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
> > Voice: (206) 236-1676 Mercer Island, WA 98040-0820
> > Fax: (206) 232-9186 Skype: jwccsllc (206) 855-5792
> >
> > The aim of public information is not to spread enlightenment at
> > all. It is simply to reduce as many individuals as possible to
> > the same level, to a breed of standard citizenry, to put down
> > dissent and originality. -- H. L. Mencken
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Fri, 18 Mar 2016 16:40:27 -0700
> > From: Jerry Crespi <jcrespi at alliedhr.com>
> > To: filepro-list at lists.celestial.com
> > Subject: batch file of dreport commands and global variables
> > Message-ID: <20160318234309.E981422CDF1A at dorsai-01.celestial.com>
> > Content-Type: text/plain; charset="us-ascii"; format=flowed
> >
> > At 04:14 PM 3/18/2016, you wrote:
> >
> > >Hi,
> > >
> > > We run batch files consisting of 10 to 20 commands that begin with
> > >"dreport " to execute various FilePro programs (processing tables). A
> > >number of these programs all need the same variable whose content changes
> > >monthly. Is it possible to somehow declare a global variable at the
> > >beginning of the batch file and be able to use it in subsequent executions
> > >of the dreport commands?
> > >
> > >
> > >
> > > I tried declaring the variable Global and defining its content in the
> > >first program, and then declaring it Extern in later programs, but the
> > later
> > >programs do not get the variable's value. It seems to be lost between
> > >dreport executions. I also tried CALLing a short program that defined the
> > >variable and its content (again with the Global declaration) from each of
> > >the programs that need it (with the Extern declaration), and that worked
> > in
> > >some cases, but for programs that run against a file of about 20 million
> > >records, the processing would prematurely end with an out-of-memory error.
> > >
> > >
> > >
> > >Thanks,
> > >
> > >Rich
> >
> >
> > A simple way of having the variable available for all the processes
> > you are running is to include a variable name in the fp config
> > file. For example, MyGlobal
> > and set the MyGlobal to the value needed for that run.
> > (MyGlobal=neededvalue)
> >
> > Then in your processing use x=getenv("MyGlobal") and it will retrieve
> > the value into x.
> > You may need to write a script to change the value of MyGlobal in
> > fp\lib\config at the beginning of your batch file. \fp\lib\config is
> > a text file.
> >
> >
> > Jerry Crespi, Ph.D.
> > President
> > Allied Business Systems Inc.
> > V. (714) 963-5554
> > F. (714) 964-0061
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Fri, 18 Mar 2016 19:47:23 -0400
> > From: Fairlight <fairlite at fairlite.com>
> > To: filepro-list at lists.celestial.com
> > Subject: Re: Re cloud server(Fairlight)
> > Message-ID: <20160318234723.GA3770 at iglou.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> > This would have made some sort of sense if what you were saying didn't
> > violate a core principle of networking.
> >
> > https://en.wikipedia.org/wiki/Maximum_transmission_unit
> >
> > Windows can't do a 64K packet, as the largest allowed MTU size is 1500
> > bytes. And in practise, I've actually seen smaller MTUs (1436, for
> > instance, in a PPPoE over DSL scenario). Even if you enable jumbo frames,
> > the best you're getting out of it is 9000 bytes per packet, and that's
> > likely only valid inside a LAN.
> >
> > Anything over the MTU size is -automatically- fragmented into multiple
> > packets. This was beneficial in analog modem days, as you could specify a
> > smaller MTU, and thus ensure that smaller packets for things like single
> > characters in telnet got a bit better turn at the trough within the stack,
> > compared to a solidly filled FTP data connection.
> >
> > Now, you -can- adjust NFS to something like an 8KB size, which makes sense
> > if you have jumbo frames for the entire path. There's zero sense in trying
> > to send 64K over a single packet, though; I'm not seeing anything which
> > supports an MTU that high.
> >
> > Also, bear in mind the packet header takes up part of the maximum packet
> > size.
> >
> > In any event, Windows has to play by the same rules as everyone else with a
> > standard TCP/IP stack. Issue this at a command prompt:
> >
> > netsh interface ipv4 show subinterfaces
> >
> > I'm on Windows 7 Professional 64-bit, and I've got a giant size only on
> > loopback. Bluetooth is 1477. Everything else (including my VMWare,
> > ethernet, and wireless connections are all 1500.
> >
> > So honestly, I don't know what the hell you're talking about with the
> > 64K nonsense. Sure, they can try to send it, but the TCP/IP stack will
> > automagically fragment a packet that size into 45 normal packets, given an
> > MTU of 1500, and the TCP header size of 20 bytes. 65536 / 1480 is 44.281,
> > so 45 packets.
> >
> > The only time you really run into problems with small packets is in
> > contention against larger packets, which will take more time on a smaller
> > pipe (read: analog modem speeds). Packet size hasn't been a valid limiting
> > factor since we moved past analog modems, honestly.
> >
> > I've heard of adjusting window sizes, but I don't think that has anything
> > to do with bypassing the MTU. I could be wrong; I'm not a dedicated
> > network engineer. But I've never seen an MTU change dynamically on an
> > interface under -any- OS. I suspect whatever is scaling would scale
> > application-level packets to multiples of the packet data size so that you
> > don't fragment and inject 'air' into your last TCP/IP packet.
> >
> > At least part of what you said is incorrect, according to everything I've
> > learned, combined with an actual -look- at the Windows TCP/IP stack
> > settings on a production system.
> >
> > mark->
> >
> > On Fri, Mar 18, 2016 at 03:34:39PM +0000, Jason Garner via Filepro-list
> > thus spoke:
> > > Interesting conversation you guys are having.
> > >
> > > Our FilePro applications here have anywhere from 40 to 70mbps bursts on a
> > > gigabit pipe.
> > >
> > > The problem with Windows and smb file transfers is that it does not like
> > > lots of small data transfers over the network. Linux has always been
> > better
> > > at handling network data transmissions and multicast streaming stuff
> > > because it is very good at automatically adjusting the TCP transmit and
> > > receive side window scaling.
> > >
> > > Windows takes a very Henry Ford type of approach to this. You can
> > transmit
> > > any size data chunk you like, so long as its transmitted in a 64k
> > payload.
> > >
> > > Filepro transmissions are small..1k 4k etc. So in that 40 to 70mbps, you
> > > are only really sending probably 10mbps. The rest of it is air.
> > >
> > > So I almost kind of wonder if you had a 100/10 cable connection if you
> > > would notice much of a difference.
> > >
> > > There is also 3rd party software you can install that does compression
> > and
> > > also auto adjusts the TCP windows on the fly. It might be doable, who
> > knows.
> > >
> > > On Fri, Mar 18, 2016 at 5:33 AM <
> > filepro-list-request at lists.celestial.com>
> > > wrote:
> > >
> > > > Send Filepro-list mailing list submissions to
> > > > filepro-list at lists.celestial.com
> > > >
> > > > To subscribe or unsubscribe via the World Wide Web, visit
> > > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > > > or, via email, send a message with subject or body 'help' to
> > > > filepro-list-request at lists.celestial.com
> > > >
> > > > You can reach the person managing the list at
> > > > filepro-list-owner at lists.celestial.com
> > > >
> > > > When replying, please edit your Subject line so it is more specific
> > > > than "Re: Contents of Filepro-list digest..."
> > > >
> > > >
> > > > Today's Topics:
> > > >
> > > > 1. Re: cloud server (Fairlight)
> > > > 2. Re: cloud server (Jose Lerebours)
> > > > 3. Re: cloud server (Fairlight)
> > > > 4. Re: cloud server (Fairlight)
> > > >
> > > >
> > > > ----------------------------------------------------------------------
> > > >
> > > > Message: 1
> > > > Date: Thu, 17 Mar 2016 19:22:25 -0400
> > > > From: Fairlight <fairlite at fairlite.com>
> > > > To: filepro-list at lists.celestial.com
> > > > Subject: Re: cloud server
> > > > Message-ID: <20160317232225.GY24133 at iglou.com>
> > > > Content-Type: text/plain; charset=iso-8859-1
> > > >
> > > > Are you actually intending to use it as realtime storage, or backup
> > for the
> > > > application?
> > > >
> > > > If realtime, you're nuts. If you think Windows clients perform poorly
> > on a
> > > > LAN when they have to drag the whole index over to look something up,
> > wait
> > > > until you slow it down to only broadband speeds, unless you're on
> > something
> > > > like Google Fiber or maybe FIOS.
> > > >
> > > > If backup, that's another story altogether.
> > > >
> > > > m->
> > > >
> > > > On Thu, Mar 17, 2016 at 06:28:27PM -0400, Jose Lerebours via
> > Filepro-list
> > > > thus spoke:
> > > > > 250GB or better.
> > > > > filePro application.
> > > > > price, well, as affordable as possible.
> > > > >
> > > > > 250GB or 20GB makes no much of a difference given that it will be
> > > > > for a lightweight filePro application.
> > > > >
> > > > > thanks,
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 03/17/2016 06:24 PM, Fairlight via Filepro-list wrote:
> > > > > >On Thu, Mar 17, 2016 at 06:08:10PM -0400, Jose Lerebours via
> > > > Filepro-list thus spoke:
> > > > > >>Who do you guys use or recommend out there?
> > > > > >>
> > > > > >>preferably unix but will settle for linux.
> > > > > >For what kind of use? Documents? Whole system backups? Something
> > > > else?
> > > > > >
> > > > > >How much space do you need?
> > > > > >
> > > > > >What price range is acceptable?
> > > > > >
> > > > > >NEI ? Not Enough Information
> > > > > >
> > > > > >m->
> > > > >
> > > > > _______________________________________________
> > > > > Filepro-list mailing list
> > > > > Filepro-list at lists.celestial.com
> > > > > Subscribe/Unsubscribe/Subscription Changes
> > > > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > > > >
> > > >
> > > > --
> > > > Audio panton, cogito singularis.
> > > >
> > > >
> > > > ------------------------------
> > > >
> > > > Message: 2
> > > > Date: Thu, 17 Mar 2016 19:47:17 -0400
> > > > From: Jose Lerebours <fpgroups at gmail.com>
> > > > To: filepro-list at lists.celestial.com
> > > > Subject: Re: cloud server
> > > > Message-ID: <56EB4205.7060203 at gmail.com>
> > > > Content-Type: text/plain; charset=windows-1252; format=flowed
> > > >
> > > > I must confess, this is totally new to me. It blows my mind how is it
> > > > that today we talk about terrabites, gigabites and 10,000mbps up/down
> > > > etc. and still look at it as "slow".
> > > >
> > > > In the not so far back times, xenix with 28k modem and a 10mb hd ran an
> > > > outfit with nothing more than a couple of multiplexers to handle all
> > the
> > > > serial lines between locations.
> > > >
> > > > You mention "windows clients" - Is the drag caused by the client or the
> > > > application? I really never heard of filePro to be a drag or hog for
> > > > bandwidth.
> > > >
> > > > I appreciate the educational info!
> > > >
> > > > Thanks,
> > > >
> > > >
> > > >
> > > >
> > > > On 03/17/2016 07:22 PM, Fairlight via Filepro-list wrote:
> > > > > Are you actually intending to use it as realtime storage, or backup
> > for
> > > > the
> > > > > application?
> > > > >
> > > > > If realtime, you're nuts. If you think Windows clients perform
> > poorly
> > > > on a
> > > > > LAN when they have to drag the whole index over to look something up,
> > > > wait
> > > > > until you slow it down to only broadband speeds, unless you're on
> > > > something
> > > > > like Google Fiber or maybe FIOS.
> > > > >
> > > > > If backup, that's another story altogether.
> > > > >
> > > > > m->
> > > > >
> > > > > On Thu, Mar 17, 2016 at 06:28:27PM -0400, Jose Lerebours via
> > > > Filepro-list thus spoke:
> > > > >> 250GB or better.
> > > > >> filePro application.
> > > > >> price, well, as affordable as possible.
> > > > >>
> > > > >> 250GB or 20GB makes no much of a difference given that it will be
> > > > >> for a lightweight filePro application.
> > > > >>
> > > > >> thanks,
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On 03/17/2016 06:24 PM, Fairlight via Filepro-list wrote:
> > > > >>> On Thu, Mar 17, 2016 at 06:08:10PM -0400, Jose Lerebours via
> > > > Filepro-list thus spoke:
> > > > >>>> Who do you guys use or recommend out there?
> > > > >>>>
> > > > >>>> preferably unix but will settle for linux.
> > > > >>> For what kind of use? Documents? Whole system backups? Something
> > > > else?
> > > > >>>
> > > > >>> How much space do you need?
> > > > >>>
> > > > >>> What price range is acceptable?
> > > > >>>
> > > > >>> NEI ? Not Enough Information
> > > > >>>
> > > > >>> m->
> > > > >> _______________________________________________
> > > > >> Filepro-list mailing list
> > > > >> Filepro-list at lists.celestial.com
> > > > >> Subscribe/Unsubscribe/Subscription Changes
> > > > >> http://mailman.celestial.com/mailman/listinfo/filepro-list
> > > > >>
> > > >
> > > >
> > > >
> > > > ------------------------------
> > > >
> > > > Message: 3
> > > > Date: Thu, 17 Mar 2016 20:32:12 -0400
> > > > From: Fairlight <fairlite at fairlite.com>
> > > > To: filepro-list at lists.celestial.com
> > > > Subject: Re: cloud server
> > > > Message-ID: <20160318003212.GZ24133 at iglou.com>
> > > > Content-Type: text/plain; charset=iso-8859-1
> > > >
> > > > On Thu, Mar 17, 2016 at 07:47:17PM -0400, Jose Lerebours via
> > Filepro-list
> > > > thus spoke:
> > > > > I must confess, this is totally new to me. It blows my mind how is
> > > > > it that today we talk about terrabites, gigabites and 10,000mbps
> > > > > up/down etc. and still look at it as "slow".
> > > > >
> > > > > In the not so far back times, xenix with 28k modem and a 10mb hd ran
> > > > > an outfit with nothing more than a couple of multiplexers to handle
> > > > > all the serial lines between locations.
> > > > >
> > > > > You mention "windows clients" - Is the drag caused by the client or
> > > > > the application? I really never heard of filePro to be a drag or
> > > > > hog for bandwidth.
> > > > >
> > > > > I appreciate the educational info!
> > > >
> > > > The problem is that storage sizes are increasing simultaneously with
> > > > transmission speeds.
> > > >
> > > > Sure, I used to have only 500GB of storage and a 1.5mbit down, 256kbit
> > up
> > > > ADSL circuit. Now I have 62mbit down, 6.2mbit up cable broadband, but
> > I
> > > > also have 6TB of storage space to back up. Not all of that is in use,
> > but
> > > > it's my capacity.
> > > >
> > > > With compression, it takes 4.5 days to do a full backup and validation
> > > > with Acronis TrueImage to a WD EX4 NAS on my WiFi LAN. That's actually
> > > > the recommended idiom for the EX4, is putting it directly on your
> > router.
> > > > I had it directly hooked to the 1GB ethernet on my system at first, and
> > > > I saw -no- speed improvement at all. It's the WD EX4's CPU, which is
> > > > under-specced for the throughput of anything higher than 50mbit.
> > > >
> > > > As I was saying, it takes 4.5 days ? to back up only 2.46TB of data in
> > a
> > > > LAN situation.
> > > >
> > > > Backup tech has not kept pace with the growing capacity of
> > > > consumer-oriented, commoditised storage. To get anything fast -and-
> > large,
> > > > you need to spend thousands. That EX4 was $600. I remember looking at
> > > > other solutions, "real" NAS vendors, SAN, etc. It is -not- affordable
> > > > unless you have a huge revenue stream to justify getting into it.
> > > >
> > > > In general, a lot of things have fallen by the wayside during this
> > period
> > > > of tech growth since 1993. Games used to have tightly written netcode
> > > > which could work over dialup, and now developers struggle to get
> > > > multiplayer working properly with a lot lower latency connections on
> > > > broadband. A whole Linux -distribution- used to be able to run on a
> > 4MB
> > > > 386sx/25 (including TinyX!), and now the -kernel- won't even fit into
> > 4MB,
> > > > let alone applications. The linux kernel started requiring more RAM at
> > > > version 2.4. I know, as the Cobalt Qube I had required a firmware
> > flash to
> > > > let it take anything newer than 2.2. So on the whole, tech is getting
> > to
> > > > be less expensive, we have more capacity, higher speeds, and...fallen
> > > > standards. That's a bad scenario any day of the week.
> > > >
> > > > As for the Windows/filePro/networking/speed issue, you have to
> > understand
> > > > what's happening under the hood. The same thing holds true on Windows
> > and
> > > > in *nix over NFS, by the way.
> > > >
> > > > Basically, think about your key or data segment. I really only ever
> > use
> > > > key, so we'll standardise on that for the scope of this discussion.
> > If you
> > > > look at your key, it's the full set of data. If you're working with
> > > > relational tables, it's more than one key file, as well. Let's say
> > those
> > > > are the 32-bit limit of 2GB in size, just for the sake of argument.
> > Now,
> > > > you have indexes. Those are much smaller files which contain
> > information
> > > > which keeps you from having to sequentially read up to 2GB worth of
> > data
> > > > every time you want something. But if you reference the spec for
> > indexes
> > > > at http://fptech.com/Products/Docs/FPFormat/autoix45.shtml you'll see
> > the
> > > > math behind the BTree+ indexes. You can figure out what fields you've
> > used
> > > > for an index, do the math, and extrapolate out to the index size for a
> > 2GB
> > > > file.
> > > >
> > > > Every time you look something up, the index is read. I'm not sure if
> > the
> > > > whole index needs to be read, or if BTree+ lets you stop early in the
> > tree
> > > > once you find what you're looking for. It really probably depends on
> > the
> > > > purpose. If you're running a report, it's probably more likely to
> > need the
> > > > whole thing than if you're searching for a specific record. But
> > assume you
> > > > need the whole index. Where's it stored? It's stored either on the
> > > > Windows server hosting the files, or it's stored on a NAS/SAN for *nix,
> > > > usually under NFS. In Windows, your client applications must drag it
> > over
> > > > the network to read it, since there's no local copy. This isn't like
> > SQL,
> > > > where you submit a query and the server handles the heavy lifting. The
> > > > filePro binaries on the client run identically to the ones on the
> > server,
> > > > meaning they must read the whole file ? except the clients must read it
> > > > across the network. That entails IP, TCP, -and- protocol-level network
> > > > overhead. The same is true of *nix systems using NFS or CIFS for their
> > > > storage. And I can tell you that NFS was originally designed -so-
> > bloated
> > > > that it was never meant to run on under 10mbit, just due to the
> > overhead.
> > > > It is -not- an elegant protocol. It has probably improved by v4, but
> > > > still, it's not lightweight.
> > > >
> > > > This is the difference between client-server architectures:
> > > >
> > > > * With SQL the server takes a tiny query, does the heavy lifting
> > directly
> > > > on the server, and spits out -only- the result. All file
> > manipulation
> > > > is in local storage (unless a SAN is involved, which is definitely
> > > > possible in large deployment scenarios, but it's still less of an
> > issue
> > > > due to the way the engines are optimised, and the faster protocols
> > > > often in play (iSCSI being one example). Also, you usually design
> > > > the servers with decent provisioning and enough RAM to cache
> > decently.
> > > >
> > > > * With filePro, the server is simply a datastore. The 'client' is
> > really
> > > > written identically to the server, and requires that the index be
> > read
> > > > (possibly fully) in order to obtain the address within the key file
> > to
> > > > seek to to read the -actual- data. Then it has to actually seek
> > there
> > > > and grab the data from the key file. I can't speak to CIFS, but
> > NFSv2
> > > > and higher support and perform seek() on the server-side, so at
> > least
> > > > it doesn't have to ship the key file up to the seek point plus
> > record
> > > > size. That said, if you are running a report which has to access a
> > lot
> > > > of (or all!) records, you -will- be shipping the majority or
> > entirety
> > > > of the key file over as well, since the non-index data is not
> > stored in
> > > > the index.
> > > >
> > > > And this is why the fP client/server "model" sucks, compared to SQL.
> > Well,
> > > > one amongst several reasons. We could get into the whole ACL issue,
> > but
> > > > that's outside the scope of this discussion. There are others, as
> > well.
> > > >
> > > > Doing this processing with large files on gigabit LAN is one thing,
> > > > although -still- painful, depending on the elegance/efficiency of the
> > > > coding, and the job requirements. Doing it over mere broadband which
> > > > crosses even one hop which is narrower? That's going to be far less
> > > > pleasant. Also, you need to take fault tolerance (or lack thereof)
> > into
> > > > account. Across a WAN, iSCSI is a Very Bad Idea[tm]. I've hit fault
> > > > tolerance issues with it on a LAN. I don't want to think about it on a
> > > > WAN. An edge router falls over for some reason (RAM exhaused, BGP
> > table
> > > > falls on the floor, name it...), and you've suddenly got a risk of data
> > > > corruption.
> > > >
> > > > Oh, and compounding the issue, I'm guessing a lot of filePro "thin
> > client"
> > > > boxes are built with very little RAM. That's going to make disk
> > caching
> > > > next to non-existent, which means you can't even count on caching for
> > > > performance benefits.
> > > >
> > > > I would strongly recommend rethinking using cloud storage in realtime
> > with
> > > > filePro.
> > > >
> > > > mark->
> > > > --
> > > > Audio panton, cogito singularis.
> > > >
> > > >
> > > > ------------------------------
> > > >
> > > > Message: 4
> > > > Date: Thu, 17 Mar 2016 20:34:40 -0400
> > > > From: Fairlight <fairlite at fairlite.com>
> > > > To: filepro-list at lists.celestial.com
> > > > Subject: Re: cloud server
> > > > Message-ID: <20160318003440.GA24133 at iglou.com>
> > > > Content-Type: text/plain; charset=iso-8859-1
> > > >
> > > > He may be. He wasn't explicit.
> > > >
> > > > If it's a "terminal session only" scenario to a VPS or other VM where
> > fP is
> > > > hosted and run natively on the same storage as the data, okay, that
> > may be
> > > > fine.
> > > >
> > > > If it's a situation where the data itself is stored somewhere in the
> > cloud,
> > > > and a share from Timbuktu is mounted to some internal Linux system,
> > you're
> > > > talking about a nightmare.
> > > >
> > > > mark->
> > > >
> > > > On Thu, Mar 17, 2016 at 08:08:29PM -0400, Scott Walker thus spoke:
> > > > > Mark,
> > > > >
> > > > > I think Jose is talking about using Linux. This is not going to be
> > > > Windows
> > > > > filepro, but fp running on Linux. Only something like Anziowin will
> > be
> > > > > running on the client side, emulating a terminal. No speed issue
> > running
> > > > > over the internet.
> > > > >
> > > > > I have customers do it all day long. Response time is good.
> > > > >
> > > > > Sorry to reply directly to you guys but my posts to the list are
> > bouncing
> > > > > again.
> > > > >
> > > > > Regards,
> > > > > Scott
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Filepro-list
> > > > > [mailto:filepro-list-bounces+scottwalker
> > > > =ramsystemscorp.com at lists.celestial.
> > > > > com] On Behalf Of Jose Lerebours via Filepro-list
> > > > > Sent: Thursday, March 17, 2016 7:47 PM
> > > > > To: filepro-list at lists.celestial.com
> > > > > Subject: Re: cloud server
> > > > >
> > > > > I must confess, this is totally new to me. It blows my mind how is
> > it
> > > > that
> > > > > today we talk about terrabites, gigabites and 10,000mbps up/down
> > etc. and
> > > > > still look at it as "slow".
> > > > >
> > > > > In the not so far back times, xenix with 28k modem and a 10mb hd ran
> > an
> > > > > outfit with nothing more than a couple of multiplexers to handle all
> > the
> > > > > serial lines between locations.
> > > > >
> > > > > You mention "windows clients" - Is the drag caused by the client or
> > the
> > > > > application? I really never heard of filePro to be a drag or hog for
> > > > > bandwidth.
> > > > >
> > > > > I appreciate the educational info!
> > > > >
> > > > > Thanks,
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 03/17/2016 07:22 PM, Fairlight via Filepro-list wrote:
> > > > > > Are you actually intending to use it as realtime storage, or backup
> > > > > > for the application?
> > > > > >
> > > > > > If realtime, you're nuts. If you think Windows clients perform
> > poorly
> > > > > > on a LAN when they have to drag the whole index over to look
> > something
> > > > > > up, wait until you slow it down to only broadband speeds, unless
> > > > > > you're on something like Google Fiber or maybe FIOS.
> > > > > >
> > > > > > If backup, that's another story altogether.
> > > > > >
> > > > > > m->
> > > > > >
> > > > > > On Thu, Mar 17, 2016 at 06:28:27PM -0400, Jose Lerebours via
> > > > Filepro-list
> > > > > thus spoke:
> > > > > >> 250GB or better.
> > > > > >> filePro application.
> > > > > >> price, well, as affordable as possible.
> > > > > >>
> > > > > >> 250GB or 20GB makes no much of a difference given that it will be
> > for
> > > > > >> a lightweight filePro application.
> > > > > >>
> > > > > >> thanks,
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On 03/17/2016 06:24 PM, Fairlight via Filepro-list wrote:
> > > > > >>> On Thu, Mar 17, 2016 at 06:08:10PM -0400, Jose Lerebours via
> > > > > Filepro-list thus spoke:
> > > > > >>>> Who do you guys use or recommend out there?
> > > > > >>>>
> > > > > >>>> preferably unix but will settle for linux.
> > > > > >>> For what kind of use? Documents? Whole system backups?
> > Something
> > > > > else?
> > > > > >>>
> > > > > >>> How much space do you need?
> > > > > >>>
> > > > > >>> What price range is acceptable?
> > > > > >>>
> > > > > >>> NEI ? Not Enough Information
> > > > > >>>
> > > > > >>> m->
> > > > > >> _______________________________________________
> > > > > >> Filepro-list mailing list
> > > > > >> Filepro-list at lists.celestial.com
> > > > > >> Subscribe/Unsubscribe/Subscription Changes
> > > > > >> http://mailman.celestial.com/mailman/listinfo/filepro-list
> > > > > >>
> > > > >
> > > > > _______________________________________________
> > > > > Filepro-list mailing list
> > > > > Filepro-list at lists.celestial.com
> > > > > Subscribe/Unsubscribe/Subscription Changes
> > > > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > > > >
> > > > >
> > > >
> > > > --
> > > > Audio panton, cogito singularis.
> > > >
> > > >
> > > > ------------------------------
> > > >
> > > > Subject: Digest Footer
> > > >
> > > > _______________________________________________
> > > > Filepro-list mailing list
> > > > Filepro-list at lists.celestial.com
> > > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > > >
> > > >
> > > > ------------------------------
> > > >
> > > > End of Filepro-list Digest, Vol 146, Issue 15
> > > > *********************************************
> > > >
> > > --
> > > Jason Garner
> > > Systems Administrator
> > > 1801 Oberlin Rd, Suite 204
> > > Middletown, PA 17057
> > > Work 717-985-1122 x 1139
> > > Mobile 717-645-3521
> > > jason.garner at evalsvs.com
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL: <
> > http://mailman.celestial.com/pipermail/filepro-list/attachments/20160318/be4de8f3/attachment.html
> > >
> > > _______________________________________________
> > > Filepro-list mailing list
> > > Filepro-list at lists.celestial.com
> > > Subscribe/Unsubscribe/Subscription Changes
> > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > >
> >
> > --
> > Audio panton, cogito singularis.
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> >
> >
> > ------------------------------
> >
> > End of Filepro-list Digest, Vol 146, Issue 19
> > *********************************************
> >
> --
> Jason Garner
> Systems Administrator
> 1801 Oberlin Rd, Suite 204
> Middletown, PA 17057
> Work 717-985-1122 x 1139
> Mobile 717-645-3521
> jason.garner at evalsvs.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20160319/483e4cd5/attachment.html>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
--
Fairlight Consulting
http://www.fairlite.com
fairlite at fairlite.com
(502) 509-3840
More information about the Filepro-list
mailing list