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